This removes subscribe UI and functionality from the main browser window,
the page info window, and from feed previews. It may leave some stray strings
in subscribe.properties/dtd, which will be removed in bug 1477669 when the
preview code goes away completely.
Differential Revision: https://phabricator.services.mozilla.com/D5982
This removes subscribe UI and functionality from the main browser window,
the page info window, and from feed previews. It may leave some stray strings
in subscribe.properties/dtd, which will be removed in bug 1477669 when the
preview code goes away completely.
Differential Revision: https://phabricator.services.mozilla.com/D5982
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
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
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
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
PanelMultiView has its own concept of "selected", so we should use this rather than move focus
using advanceFocusIntoSubTree.
MozReview-Commit-ID: DW2JqqggLl1
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
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
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
