Instead of `<xul:hbox class="textbox-input-box">`, consumers now should use
`<xul:moz-input-box />`. This covers the normal case and also handles
[spellcheck=true] while sharing much of the code within one class.
MozReview-Commit-ID: DjvT8sFq3SQ
--HG--
rename : toolkit/content/widgets/textbox.xml => toolkit/content/widgets/textbox.js
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
Before this change, we accessed the browser URL in the following ways:
- "chrome://browser/content/browser.xul"
- "chrome://browser/content/" (which redirects to chrome://browser/content/browser.xul)
- Services.prefs.getCharPref("browser.chromeURL") which returns "chrome://browser/content/"
- getBrowserURL() from utilityOverlay.js
MozReview-Commit-ID: I5vtRke1x9t
--HG--
extra : rebase_source : c525350a1954740873e85b045cbb14a8b43aa89d
PanelMultiView has its own concept of "selected", so we should use this rather than move focus
using advanceFocusIntoSubTree.
MozReview-Commit-ID: DW2JqqggLl1
--HG--
extra : rebase_source : ec7a6f83fdda176f3286cf4395dc72de6cad2466
The shims that this rule tests for no longer exist.
MozReview-Commit-ID: DMgP7Hczavc
--HG--
extra : rebase_source : 765ddd5c62c9449c07ed050e44d86a3bd5c0ae64
extra : amend_source : 627a7694ac07182200f876901ded7a34721cd228
This removes the sync reflow from almost all cases. The only case where we keep it is when a keypress
caught in content triggers a sync message to the parent process. We should clean this up in bug 1371523.
I've tried to fix the tests, but a lot of them seem to be disabled anyway...
MozReview-Commit-ID: 9k36p7q8MKy
--HG--
extra : rebase_source : 311ee41ba9456a5c5d58b81a0cfa999bcef0027e
This removes the sync reflow from almost all cases. The only case where we keep it is when a keypress
caught in content triggers a sync message to the parent process. We should clean this up in bug 1371523.
I've tried to fix the tests, but a lot of them seem to be disabled anyway...
MozReview-Commit-ID: 9k36p7q8MKy
--HG--
extra : rebase_source : 311ee41ba9456a5c5d58b81a0cfa999bcef0027e
The UIState.ON_UPDATE notification should be enough to reset the state of the
panel every time the test is about to be executed. Wrong.
In response to this notification, gSync.onActivityStop() is called, which disables
the syncing animation immediately ONLY if it has been running for at least 1.5sec
(which is almost never happening in tests), otherwise we get a setTimeout with
the remaining time.
When the sync animation is running, we also do not react to clicks (disabled),
hence the test failing.
We fix this by stopping the animation ourselves manually at the end of the test,
so any subsequent test will start with a correct UI state.
MozReview-Commit-ID: CrEb82Tw5SO
--HG--
extra : rebase_source : da4822c9fb6f41e6fbfeec5a63086c43aeca7944
We now use the "active" property of views to track whether navigation is possible. This has the advantage of being already handled correctly when views are moved to a different panel, and is in line with the purpose of the "active" state. The note about using the "popupshown" event for navigation has been updated accordingly.
Keyboard navigation is also linked to the "active" property now, so there is no need to track the state of the "_transitioning" property anymore.
Since the goBack and showSubView methods can only be called when the view is active, we don't need to check for attempts to start a transition while the panel is closed anymore.
MozReview-Commit-ID: 3KT3A5EwGFy
--HG--
extra : rebase_source : c338362923a7574210c7329bb84316d549898fdc
This includes both canceling the ViewShowing event and calling the hidePopup method of PanelMultiView.
MozReview-Commit-ID: Goo45SEBC3z
--HG--
extra : rebase_source : d78376d7a69dd47157e049da1aaa19e97b9bd12c
This also adds a new "active" property that can be used by regression tests to determine whether they should still wait for the ViewShown event.
MozReview-Commit-ID: K25F09llooj
--HG--
extra : rebase_source : 9f6dad605243fcd3633260c4fa34011f9cfab27c
extra : source : 2dad70b2a723e67b45563dd3ac254911dd193439
This also adds a new "active" property that can be used by regression tests to determine whether they should still wait for the ViewShown event.
MozReview-Commit-ID: K25F09llooj
--HG--
extra : rebase_source : 8c9e2a86285be6453cd60b3da448876e6dfa7e8a
