First implementation of HTML based tooltip to be used in devtools
instead of XUL panels. API is similar to the current API of
Tooltip.js
MozReview-Commit-ID: 8njiKBubLSj
--HG--
extra : rebase_source : 930bf7aef48e6c16d7a560d261e2bfd06fe02a63
extra : source : 09874a1e6f2c942a1f9de827fedd14da7e67a6e5
This is still not completely perfect in that in principle it is possible for add-ons to add toolbars that they force to be non-transparent, but there is no way to select for that. Keeping a list of toolbars we know are transparent would break the more common case of third-party toolbars that do behave 'normally' when used with lightweight themes. So for now, just assume navigator-toolbox is all transparent when a lwtheme is in use.
MozReview-Commit-ID: 4I8l3Bn7DQf
--HG--
extra : rebase_source : 58aa9e76fee1df7530bef592cb360f45fe936f2d
This allows us to restore the previously opened bookmarks folder when returning to
the bookmarks panel. I.e. when you open a bookmarks folder (including the smartfolders),
select a bookmark, and then return (via the back button, or quick-history via long-pressing
the back button), we will return to the bookmarks folder that was opened.
We don't persist the scroll position, that's a separate issue, in Bug 993552.
MozReview-Commit-ID: 3EhIvlXOgAU
--HG--
extra : rebase_source : 17e903622d20a922d46c1319191b051cf592a4c0
All home panel state is currently discarded when you navigate to another page.
We want to be able to restore state (e.g. to return to the currently opened bookmarks folder,
instead of returning to the root of the bookmarks folder). This commit adds storage and a framework
to allow homepanels to persist data.
MozReview-Commit-ID: GWDX7UZrIZs
--HG--
extra : rebase_source : d0959196e14496b7970ad14df39937c67013624f
I initially wrote the "ForGivenDate" variant for testing purposes - so I could
verify the daylight savings time APIs worked the way I expected them to.
However, I ended up using it in my next patch and leaving in the generic "for
current time" variant because it seems useful.
MozReview-Commit-ID: 4hNGD4uDuOj
--HG--
extra : rebase_source : 56cd92c7ef95aa5ca54daa27d93f56a053f7b4df
The format we chose comes from Desktop - bug 1144778.
MozReview-Commit-ID: 9eXb78d70pM
--HG--
extra : rebase_source : 937e121be41bb587764029d8abcc72bd183e7328
I followed the guide at:
https://wiki.mozilla.org/Mobile/Fennec/Android/Task_Cluster_notes
To identify what to change.
MozReview-Commit-ID: HnKSSqym0aA
--HG--
rename : testing/mozharness/configs/builds/releng_sub_android_configs/64_api_15_frontend.py => testing/mozharness/configs/builds/releng_sub_android_configs/64_test.py
rename : testing/taskcluster/tasks/builds/android_api_15_frontend.yml => testing/taskcluster/tasks/builds/android_test.yml
extra : rebase_source : a4080ecc8afab781cbd81de7b2d2c1f9b3968757
Previously, the targetNodeCb used in TooltipToggle had an inconsistent API. If
returning synchronously, "false" would prevent the tooltip from appearing.
However, if using a promise, resolving "false" would still show the tooltip.
It was needed to reject the promise in this case to prevent the tooltip from
being displayed.
This commit makes TooltipToggle always expect a consistent return value from
this callback, whether it is synchronous, or using promises.
- true -> show the tooltip on the event target
- DOM node -> show the tooltip on the provided node
- false (or falsy value) -> do not show the tooltip
MozReview-Commit-ID: 7PIPwBJxjWO
--HG--
extra : rebase_source : 279bab30f631a3a65a93b52226c6980210abf2f1
The code used to make the tooltip appear/disappear when hovering targets
has been extracted to a separate class that can be shared between the
current Tooltip.js implementation and the upcoming HTMLTooltip.
MozReview-Commit-ID: UYSjPFeMYK
--HG--
extra : rebase_source : 5dcca2d5887ffc98fec621092640073a0909c13f
Julian Descottes
Gijs Kruitbosch
Andrzej Hunt
Michael Comella
J. Ryan Stinnett
Krishna
Grigory Kruglov
Margaret Leibovic
Eddy Bruel
Carsten "Tomcat" Book
ffxbld
Wes Kocher
Joel Maher