The Animation and KeyframeEffect constructors and the finshed promise are not
enabled on release channel currently. The polyfill is added to make sure
we don't break on release.
When the feature ships, removing the polyfill should be as easy as
reverting this changeset.
MozReview-Commit-ID: 2EWN7hBN5tj
--HG--
extra : rebase_source : 19290268e281fc631458eb64745bea000994c3e7
Web Animation API should give us deterministic timing when the transition ends or aborts.
Additional clean-ups:
- Make sure hidden status is always set/get from the hidden property,
instead of the hidden attribute.
- Remove the unused isControlBarHidden property.
- controlsSpacer no longer has a background color (removed in bug 1374007),
therefore it no longer needs a transition and there is no need to test
its state with the test added in bug 1319301.
- Fix a logic error at hideByAdjustment property, revealed by the changed
transition timing, in which adjustControlSize() would show the controlBar
set hidden by the transition.
MozReview-Commit-ID: DB2cgQcUEXi
--HG--
extra : rebase_source : 2a715038197aa29d3eaf837fad85797ec1e98b15
This is only applied to menubars already, and this binding is not extended, so
should be an idempotent change.
MozReview-Commit-ID: 8DiDTC8KBjR
--HG--
extra : rebase_source : c80abf06eca30bdd478083693342ce2c277d5e22
NullPrincipal::Create() (will null OA) may cause an OriginAttributes bypass.
We change Create() so OriginAttributes is no longer optional, and rename
Create() with no arguments to make it more explicit about what the caller is doing.
MozReview-Commit-ID: 7DQGlgh1tgJ
Channel layout is derived by the content being played. The concept of preferred layout is meaningless. Either we have a layout defined, or we don't. There's no in-between.
So we remove it.
MozReview-Commit-ID: CSCAInNmzMS
Fades out all the UIs by applying CSS transition on opacity and visibility.
Stop relying on transitionend event to set the hidden state.
This removes a source of intermittent failure and while making sure UIs are
hidden.
MozReview-Commit-ID: FR7JQn4eO3X
--HG--
extra : rebase_source : d62faf9eb8c1cab72e9a0e445974be67e7ff5c85
Convert all is* methods to getter or rename them if they take arguments.
MozReview-Commit-ID: GOJzz0JYGnq
--HG--
extra : rebase_source : 86539c3e5d85b2d6cbe1455e2b36f8e831773b2e
Enlarge controls by around 1.3x, which is the size of the original touch controls.
MozReview-Commit-ID: kpgFFIW2hh
--HG--
extra : rebase_source : 66636a0cb15a17ef15c2a2307a2f9100c1852480
extra : source : ae615321dc9b3e6276d8e79285d0e9d65b6d6bc2
The videocontrols binding will be destroyed and reattached when the video
enters/leaves fullscreen. This change accounts for that so that screen
orientation is correctly set on mobile.
MozReview-Commit-ID: 7D1gkiuXZtX
--HG--
extra : rebase_source : 61612a04af72e8297f6c54cfe66c097b97a76634
Also migrates TouchUtils to videoControls in order to keep some interactions.
Removed the casting button from TouchUtils (to be add back to Utils in the next
commit; not removing the SVG images for hg annotation)
MozReview-Commit-ID: DzhmjykCLzu
--HG--
extra : rebase_source : d77dfe3e2d9de2087d21dc2fb9b1773e710177d7
The noControls binding is bound to <video> without controls on mobile
(see geckoview/content.css), and is only visible when the video is
blocked because of background autoplay.
MozReview-Commit-ID: KZqlQedCjd5
--HG--
extra : rebase_source : c5f619b0849ee56f957e9017ab2627d592a3285e
We'll start to dispatch keydown event and keyup event even during composition.
So, for testing those events won't break our UI, we should make
EventUtils.synhtesizeComposition() and EventUtils.synthesizeCompositionChange()
dispatch keydown event and keyup event even if callers don't specify keyboard
event explicitly.
Typically, "keydown" event is marked as "processed by IME", i.e., keyCode
value is set to DOM_VK_PROCESSKEY and key is set to "Process", with our
widget which handles native IME and key input. On the other hand, "keyup"
is NOT marked as so.
Therefore, this patch makes TextInputProcessor emulates this behavior without
any new special flags. And for making possible to emulate special cases,
this patch adds two flags to nsITextInputProcessor. One is
KEY_DONT_MARK_KEYDOWN_AS_PROCESSED. The other is KEY_MARK_KEYUP_AS_PROCESSED.
Unfortunately, those flags have opposite meaning but this must be better than
making necessary to one flag for emulating usual keydown/keyup events.
Finally, this makes some tests specify better keyboard information to
synthesizeComposition() and synthesizeCompositionChange() to emulate
actual keyboard events during composition.
MozReview-Commit-ID: ItYaXILkNQE
--HG--
extra : rebase_source : e50cc77c1efbc12686d7ea334d41926c7392b30d
The shims that this rule tests for no longer exist.
MozReview-Commit-ID: DMgP7Hczavc
--HG--
extra : rebase_source : 765ddd5c62c9449c07ed050e44d86a3bd5c0ae64
extra : amend_source : 627a7694ac07182200f876901ded7a34721cd228
This policy disables the safe-mode UI entry points. In addition, only on Windows when using GPO, it also disables entering Safe Mode by holding down the Shift Key
This policy disables the safe-mode UI entry points. In addition, only on Windows when using GPO, it also disables entering Safe Mode by holding down the Shift Key
This patch renders error message for the Simplify Page document when
Reader Mode fails to parse original document. This patch also adds a test
to reliably produce a readable document that returns a parsing error when
run through the readability library.
MozReview-Commit-ID: 686mBkU9eVM
--HG--
extra : rebase_source : 154e840c89e0c8ff380dc9551c8fde93711d510d
Ensure remoteWebProgress is initialized for remote browsers. Includes devtools fix from jryans.
MozReview-Commit-ID: Ce3TzwkNnyi
--HG--
extra : rebase_source : 0f2bcb96ef04f4eaee447180dc21400dca3bf410
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
console.assert keeps the same semantics as NS_ASSERT in that it doesn't throw an exception,
but a lot of the places code was using it in a way that would be better served by throwing
an exception when the condition is false.
MozReview-Commit-ID: DEF5HSfYO36
It seems that the layout system assumes those attributes are for size of
the <window> element, i.e. inner window size, not outer window size.
See for example nsContainerFrame::SyncWindowProperties. It reads
{min,max}{width,height} attributes from the element via
nsIFrame::GetXUL{Min,Max}Size, and passes them into SetSizeConstraints.
The latter inflates the sizes with window decoration size before calling
into widget code. It can also be seen that various XUL size related
methods on nsBox and nsIFrame put the same assumption.
The test test_windowminmaxsize.xul apparently puts the same assumption
as the layout system on the meaning of those properties.
(Another test test_resize_move_windows.xul, which tests effectiveness of
features of window.open, also fails if we size the window earlier than
current in bug 1439875, and doesn't fail with this patch on top. It may
indicate that it makes use of the same assumption, but I can't really
figure out how it does so.)
MozReview-Commit-ID: IdMwDc59Ltg
--HG--
extra : rebase_source : ae46c23e450f556cc4608b512890c4e27cf8623e
- Remove the colorpickertile binding as it's no longer useful.
- Remove nsAccessibilityService::CreateAccessibleByType() as it has nothing to do anymore.
- Remove nsCoreUtils::XBLBindingRole()
MozReview-Commit-ID: E21yljdsSLl
--HG--
extra : rebase_source : f0db5893107ee0c493291c7c0bafaaef1d4bcffa
The overlay defined two elements (helpMenu, menu_ToolsPopup) for all
platforms and three others (windowMenu, baseMenuCommandSet, baseMenuKeyset)
that were MacOS only. The two all platform elements and windowMenu were only
used once and inlined into browser-menubar.inc. The rest of the MacOS only
elements were conditionally inlined into browser-sets.inc.
MozReview-Commit-ID: D2uyCrnepuH
--HG--
extra : rebase_source : a3f7ecaf70c55574ee87091027a651ce429c6876
This also changes the const values of nsIEnterprisePolicies to a more common numbering pattern.
MozReview-Commit-ID: CKs1TWGMqJN
--HG--
extra : rebase_source : 117a6587e56ffbe9a10818b93ed42bb8583a4826
The overlay elements with children of editMenuOverlay.xul are moved into
include files (editMenuCommands.inc.xul and editMenuKeys.inc.xul). For
the other single elements in the overlay, the attributes are inlined
wherever they are used.
MozReview-Commit-ID: 792cuzUvQxT
--HG--
extra : rebase_source : 58e4c05bde16cee873d37c6198de102d048499c2
* Code in XMLHttpRequestMainThread is converted to set the username and password individually. This is because when the parameters are empty, it ended up calling SetUserPass(":") which always returns an error.
MozReview-Commit-ID: 3cK5HeyzjFE
--HG--
extra : rebase_source : f34400c11245d88648b0ae9c196637628afa9517
This test is already marked fails-if on Windows 8 and all OSX. With
run-by-manifest enabled it also starts failing on Windows 7 and 10. The fix
will be tracked in bug 1439988.
MozReview-Commit-ID: 14xidhwXCue
--HG--
extra : rebase_source : 391fbc0d0b3ee349cde9cb5d57ac9c3cb1d36bcc
This patch intentionally re-map the following controls from button to toolbarbutton
- browser/components/downloads/content/download.xml#download-subview-toolbarbutton
- toolkit/content/widgets/toolbarbutton.xml#menu-button
MozReview-Commit-ID: E806LA6NAvC
--HG--
extra : rebase_source : 8e7534dc34f95e1d0cc6d00370475cc796acc36e
When background tabs crash, they were being replaced by about:blank tab
hosted in parent process.
Now that there is a mechanism for lazily creating browsers, discarding the
crashed background browser until they are selected is a cheaper operation
(compared to creating about:blank).
Certain test cases were also updated to take into account the new scenario.
--HG--
extra : rebase_source : ab2c6c7b2faf5710ebfc52259632fbcd6d67b5fa
extra : amend_source : 0e15fb0f4818273daa3438d4e297f42558c1fc55
The second notification is needless and can cause deadlocks. The code
previously tried to ensure it wasn't sent, but didn't account for
the possibility of a call to hidePopup() causing the 'popuphidden'
event to be handled synchronously.
MozReview-Commit-ID: BiMOFMMudIH
--HG--
extra : rebase_source : 060319da29f313d30b380dcecd6fc73ff5a807e8
The autocomplete module listens to keypress event for both printable keys and
non-printable keys a lot. However, we'll stop dispatching keypress event for
non-printable keys in the default event group of web content. So, autocomplete
should listen to keypress events at the system event group.
Note that it's difficult to change keypress event listeners to keydown event
listeners because if we stop keypress events at preceding keydown event in
autocomplete or satchel module, some other modules fail to handle keydown or
keypress event before autocomplete and it's not easy to investigate which
module's which keypress event listener should be changed to keydown event
listener. Therefore, this patch doesn't do it at least for now.
MozReview-Commit-ID: 7e3aklmKrXu
--HG--
extra : rebase_source : 1a1e71972e4f56f088c0372e12961ffb683c7b26
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
The default styles of richlistbox autocomplete were originally created to support the location bar popup, but now every autocomplete field uses the richlistbox version. This reworks the styles so that the number of overrides is minimized.
MozReview-Commit-ID: BwagKpMR5Dt
--HG--
extra : rebase_source : 52eda7f9d561dd23f279a3d15659e84f6c46eec6
* The number is no longer selected on number input focus
MozReview-Commit-ID: AmR5c6YKTCP
--HG--
extra : rebase_source : fdaab23fca57f361c9185191d9c30e047375cbe8
The only purpose of these bindings was to insert a stylesheet, which has been
moved to be included in toolkit/content/components.css.
MozReview-Commit-ID: 23jqkIrbVvi
--HG--
extra : rebase_source : 8d13f7a8afa730207d40e1457e36ec51331c4ea7
* The number is no longer selected on number input focus
MozReview-Commit-ID: EoXNqhXwK95
--HG--
extra : rebase_source : b5a522e11796ec42c87019f6c3955e6c40eb21d0
* The number is no longer selected on number input focus
MozReview-Commit-ID: 6XQdnJP65m0
--HG--
extra : rebase_source : 96d16469e99fc52c15a0b5024bdf9c3b4211a171
The events that get silenced here are already covered for native anonymous content
by IsEventStoppedFromAnonymousScrollbar.
In trees, where <xul:scrollbar> and <xul:scrollcorner> are part of the DOM, copy the
handlers over into attributes on each instance.
MozReview-Commit-ID: Huk5nFC7Qua
--HG--
extra : rebase_source : f5e596f04c6a2022b9d6019d49e61bf64422f912
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <