When defaulting to a null triggering principal, these tests would fail
when loaded remotely. This patch adds explicit system triggering
principal to the loadURI calls.
Differential Revision: https://phabricator.services.mozilla.com/D8461
As part of the conversion, support for notificationsHidden and children that are not notifications is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D10894
--HG--
rename : toolkit/content/widgets/notification.xml => toolkit/content/widgets/notificationbox.js
extra : rebase_source : 36a5412e1e9a9dc591fd486d1123c1f763a6f173
This provides a way to access specific element classes before any associated Custom Element is instantiated, without creating a new global for each class. This can be useful to access static methods, create derived classes in a page, or allow lazy custom constructors.
Differential Revision: https://phabricator.services.mozilla.com/D10893
--HG--
extra : rebase_source : 65516d2013410146b4ed372a965bd859621b74a5
This also removes testing for the unused PRIORITY_CRITICAL_BLOCK behavior, and simplifies how Print Preview hides the chrome while removing leftover code.
The only theme-specific mochitest that ever existed checked an overflow scenario that is no longer relevant, so the test and its build folder are removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D10578
--HG--
extra : rebase_source : 93276d403b85dea6bce3b678100328eb66486eaa
extra : source : aaf1a7164c5b4f75882be574edc92fd69e906129
This patch converts datetimebox.xml to datetimebox.js and loads it as a UA Widget,
while touches things here and there to make it work.
In HTMLInputElement manages the lifecycle of the datetimebox UA Widget.
It is loaded when in <input> has type date or time, or have its type switch to date or time.
nsDateTimeControlFrame is changed so that when UA Widget is enabled,
it would not generate <xul:datetimebox>.
Like bug 1483972, a check is added in nsCSSFrameConstructor::CreateGeneratedContentItem()
to make sure we don't generate pseudo content inside <input>.
Assertions in IntlUtils is changed to allow UAWidget to call the methods.
Depends on D9056
Differential Revision: https://phabricator.services.mozilla.com/D9057
--HG--
rename : toolkit/content/widgets/datetimebox.xml => toolkit/content/widgets/datetimebox.js
extra : moz-landing-system : lando
This patch simplifies the nsIDateTimeInputArea interface, implemented by the
datetimebox bindings, to a point that is easier to convert it to dispatch events,
by doing the following:
- hasBadInput() is re-implemented in C++ in nsIDateTimeControlFrame since
C++ needs the return value synchronously.
- SetValueFromPicker() and SetPickerState() are avoided completed since they
are simply called by HTMLInputElement methods exposed to the frame
script. They are avoided by having the frame script access the NAC and call
the nsIDateTimeInputArea methods directly.
- Merge setEditAttribute() and removeEditAttribute() to updateEditAttributes()
which takes no arguments, and have the method access the attribute values by
reading the values from <input>.
This patch is a scaled-down version of the patch proposed in bug 1456833.
The event approach is only usable in UA Widget version of datetimebox because
there is no way to avoid leaking events to the document without Shadow DOM.
Differential Revision: https://phabricator.services.mozilla.com/D9056
--HG--
extra : moz-landing-system : lando
See next commit for more info. The idea is to use E10SUtils.canLoadURIInRemoteType to detect
if a URI can load in a given E10SUtils process type. Having it to accept a nsIXULRuntime
process type, which will be mapped back to an E10SUtils process type, is unnecessary.
MozReview-Commit-ID: KeYkuRDyqXO
--HG--
extra : source : a8bba29ad2cb20239b87081f77cdf34249d3337b
extra : intermediate-source : 18f824674b76d87ed8cdaee516ad450c1c9b6496
extra : histedit_source : 3a0a8be23c1a5e749396d7aa8c7decbe152bc1db
See next commit for more info. The idea is to use E10SUtils.canLoadURIInRemoteType to detect
if a URI can load in a given E10SUtils process type. Having it to accept a nsIXULRuntime
process type, which will be mapped back to an E10SUtils process type, is unnecessary.
MozReview-Commit-ID: KeYkuRDyqXO
--HG--
extra : rebase_source : c4f5d562657bc1ca0a2fe7c277f09add9c976975
extra : intermediate-source : b6996abc7d90edbc99d4ac0c5b9bb4a62c5ae5ae
extra : source : a8bba29ad2cb20239b87081f77cdf34249d3337b
See next commit for more info. The idea is to use E10SUtils.canLoadURIInRemoteType to detect
if a URI can load in a given E10SUtils process type. Having it to accept a nsIXULRuntime
process type, which will be mapped back to an E10SUtils process type, is unnecessary.
MozReview-Commit-ID: KeYkuRDyqXO
--HG--
extra : rebase_source : a3f94b45b96539a969d83e4c4c10ef6f16950fb3
extra : source : a8bba29ad2cb20239b87081f77cdf34249d3337b
This is another case of a document getting loaded before MainProcessSingleton,
similar to profile manager. There's another wrinkle here, though. The migration
UI can also be loaded _after_ startup (through Bookmarks manager), which is
actually the primary way this UI is surfaced. So we need to also handle customElements.js
getting loaded twice into the same window to avoid attempting to redefine everything.
Differential Revision: https://phabricator.services.mozilla.com/D9713
--HG--
extra : moz-landing-system : lando
In order to support this, a new "findbarclose" event (mirroring the pre-existing "findbaropen" one) was added to the `MozFindbar.close` method in the findbar.js file.
Depends on D8740.
This changeset replaces calls to ok with 3 arguments to calls with 2 arguments
in situations where the switch does not have a significant impact on the assert.
Differential Revision: https://phabricator.services.mozilla.com/D8741
--HG--
extra : moz-landing-system : lando
Depends on D8739.
This changeset updates calls to ok() that were most likely intended
for is(), but are not working as is.
Differential Revision: https://phabricator.services.mozilla.com/D8740
--HG--
extra : moz-landing-system : lando
This changeset updates all the test that were wrongly using ok() and wanted to
use is() AND for which the assert is still passing without any modification
required.
Differential Revision: https://phabricator.services.mozilla.com/D8739
--HG--
extra : moz-landing-system : lando
Proper native "groupbox" styling depends on the structure of the XBL binding. By restyling the Page Info dialog, the native styling is now unused except for the Print Page Setup dialog on Windows. The native apperance is thus not applied by default anymore, and the "groupbox" element can just be used semantically for accessibility. The Print Page Setup dialog applies the native styling on its own in a way that still works on Windows.
The only other consumers of "groupbox" are the in-content Preferences pages and dialogs. These are updated to use simpler styles that don't depend on the binding structure.
Differential Revision: https://phabricator.services.mozilla.com/D8752
--HG--
extra : rebase_source : af36d911980517f9b53036f4cd4f800c5e20ad22
One important unrelated change this makes is that previously (in my other patches), the only "@" aliases we recognized were the internal "@" aliases in nsSearchService. While I was working on the new test here I realized that engines with user (or test) aliases that start with "@" aren't recognized as having "@" aliases, but why not IMO.
Differential Revision: https://phabricator.services.mozilla.com/D9074
--HG--
extra : moz-landing-system : lando
This bug touches just about every part of the urlbar: UnifiedComplete, the autocomplete binding, the formatter, CSS.
This builds on the patches in bug 1496814 and bug 1496811.
Differential Revision: https://phabricator.services.mozilla.com/D8948
--HG--
extra : moz-landing-system : lando
Support ctrl-n and ctrl-p for navigating down and up (respectively) in the url
bar on macOS. The autocomplete widget will also support the same key bindings.
This functionality matches ctrl-n/ctrl-p behavior on the other major macOS
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D6451
--HG--
extra : moz-landing-system : lando
When defaulting to a null triggering principal, these tests would fail
when loaded remotely. This patch adds explicit system triggering
principal to the loadURI calls.
Differential Revision: https://phabricator.services.mozilla.com/D8461
--HG--
extra : moz-landing-system : lando
* Remove unused xul namespace declaration.
* color and font are inherited, so no need to declare anything.
* Setting -moz-appearance: none on a div element is useless.
Differential Revision: https://phabricator.services.mozilla.com/D8656
--HG--
extra : moz-landing-system : lando
Instead set the cursor from the UA sheet, and allow authors to override it. This
matches what other UAs do.
Differential Revision: https://phabricator.services.mozilla.com/D8640
--HG--
extra : moz-landing-system : lando
This is unrelated to the other changesets in the bug, just a cleanup based on
patterns that have emerged in other attributeChangedCallbacks like in progressmeter
Differential Revision: https://phabricator.services.mozilla.com/D8174
--HG--
extra : moz-landing-system : lando
As outlined by MozXULElement, we:
- delay connectedCallback logic until after parse
- wait for isConnectedAndReady before running attributeChangedCallbacks;r=paolo
Differential Revision: https://phabricator.services.mozilla.com/D8150
--HG--
extra : moz-landing-system : lando
Adding a test to check whether the wakelock state is correct under different situations. However,
the lock state of power manager doesn't equal to the actual platform lock. Now we don't have any
way to detect whether platform lock is set correctly or not, but we can at least make sure the
specific topic's state in power manager is correct.
Differential Revision: https://phabricator.services.mozilla.com/D7355
--HG--
extra : moz-landing-system : lando
There are two reasons for this:
1) It's faster than running the connectedCallback in the middle of document parse, at least for
<radiogroups> in about:preferences
2) It provides a construction sequence more similar to XBL, so the translation from XBL <constructor>
to CE connectedCallback is more likely to be correct. This is because when there is markup like:
<parent-ce><child-ce></child-ce></parent-ce>
the parent-ce node is empty during the first connectedCallback. If we wait for DOMContentLoaded
then the parent-ce has the child-ce node below it.
Differential Revision: https://phabricator.services.mozilla.com/D7944
--HG--
extra : moz-landing-system : lando
The connectedCallback fires after it's already in the DOM, so without this attribute setting [hidden]
will animate it closed.
Differential Revision: https://phabricator.services.mozilla.com/D7930
--HG--
extra : moz-landing-system : lando
For simplicity, we do not support remote-to-non-remote or non-remote-to-remote
nsIWebProgressListener persistence.
Differential Revision: https://phabricator.services.mozilla.com/D7936
--HG--
extra : moz-landing-system : lando
Previously, the <radio> constructor just nulled out the _radioChildren of the <radiogroup>.
This leads to some issues that existed before the Custom Element migration to <radiogroup>,
in which state wouldn't get synchronized between an already-appended radiogroup and a newly
add radio (i.e. the [disabled] attribute on the radiogroup wouldn't copy down to the new radio,
and the [value] attribute wouldn't get moved up onto the radiogroup if the new radio is [selected]).
In addition to that, the Custom Element migration introduced a worse bug, in which the
XBL constructors on radio elements sometime haven't run when the radio is connected. This
means the radiogroup doesn't recognize any children, and the selectedItem / value is wrong.
This patch makes it so that the radio will notify the radiogroup when it is constructed,
and if necessary, the radiogroup can make sure all the state is consistent.
Differential Revision: https://phabricator.services.mozilla.com/D7760
--HG--
extra : moz-landing-system : lando
Move the implementation of the XBL tooltip to C++ so the element can safely
be created during native anonymous content creation. The 'mouseover' and
'mouseout' event handlers were not moved as they appear to be legacy code
that is no longer needed.
A number of tests started perma-failing after this patch. Most failures
were caused by a timing change where plugins sometimes load after the
document "load" event. Many of the failures had intermittents associated
with them and the tests were not waiting for plugins to load before
starting. The test "test_weakmap_keys_preserved2.xul" had a bug where it
was possible for it to finish before all the tests were run.
Differential Revision: https://phabricator.services.mozilla.com/D5065
--HG--
extra : moz-landing-system : lando
This fixes a regression caused by bug 1493525 and detectable by
the reftest added in bug 1367875.
The width sizing of <audio> is still broken, see bug 1495821.
Differential Revision: https://phabricator.services.mozilla.com/D7534
--HG--
extra : moz-landing-system : lando
This commit initially exposes the drawSnapshot API off of <browser>. This
is done by adding a WebIDL binding to FrameLoader and wrapping it in
browser.xml.
Differential Revision: https://phabricator.services.mozilla.com/D6791
--HG--
extra : rebase_source : 9f819b13c102edf42ab2bb2466578751a7a2f647
For compositor animations, we don't guarantee the finished promise callback
to run in the first frame after the animation finishes. By setting
fill: both, we set the animation to fill until the main thread has a chance
to catch up.
A filling animation has to be cancelled explicitly, otherwise the
value of the animating style will be locked at the last frame of the animation.
Differential Revision: https://phabricator.services.mozilla.com/D7317
--HG--
extra : moz-landing-system : lando
This also "fixes" what appears to be some broken checks by switching
them to todo()'s. I filed bug 1492885 to investigate these busted
checks, and re-enable them.
Depends on D6970
Differential Revision: https://phabricator.services.mozilla.com/D6971
--HG--
extra : moz-landing-system : lando
This is faster. It does drop support for skipping non-XUL-namespaced radiogroup
tags, but we don't have or plan to have HTML namespaced radiogroups in the same
document as a XUL-namespaced radiogroup.
Differential Revision: https://phabricator.services.mozilla.com/D7255
--HG--
extra : moz-landing-system : lando
They are unnecessary for most every element, and we load multiple dummy.xul
documents even in clean profiles.
Differential Revision: https://phabricator.services.mozilla.com/D7112
--HG--
extra : moz-landing-system : lando
Our current prioritization mechanism doesn't account for tab
warming, or for the fact that the current tab should be
deprioritized. This corrects that.
Differential Revision: https://phabricator.services.mozilla.com/D7205
--HG--
extra : moz-landing-system : lando
My reasoning in https://bugzilla.mozilla.org/show_bug.cgi?id=1484737#c3 was wrong. I assumed that if a result started with a search alias then it had to be a search alias result, but that's clearly not true.
This is such a pain to get right, and all the messy logic in this patch reflects that.
Differential Revision: https://phabricator.services.mozilla.com/D6528
--HG--
extra : moz-landing-system : lando
This patch adds a few guards to the DOM elements the videocontrols holds as
properties. Any future changes that attempt to access the blacklisted layout
properties of the DOM elements will throw.
Depends on D6725
Differential Revision: https://phabricator.services.mozilla.com/D6726
--HG--
extra : moz-landing-system : lando
Given that the videocontrols UA Widget initializes when the DOM is inserted
(as opposed to the XBL binding only when the element is visible), the code should
not be tapping into layout until it updates.
Differential Revision: https://phabricator.services.mozilla.com/D6725
--HG--
extra : moz-landing-system : lando
My understanding of Web Animation API was wrong in bug 1449532. If a running
animation is pending, playing a new (reversed) animation will cause it to
play from the beginning of the new animation, instead of having the new animation
to play, in reverse, from the current position.
This has caused the user to see a fade out animation that shouldn't take
place when the video loops, i.e. going from "seeking" to "seeked".
The code now probe into the state of the animation instance and cancel
the pending animation, reverse the running animation, or start the new
(reversed) animation accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D6704
--HG--
extra : moz-landing-system : lando
This also removes the (afaict, unused) stub implementation from TabParent. The netwerk header
inclusions were necessary because those files included TabParent.h and through it,
nsISecureBrowserUI, but now TabParent.h no longer does that.
Differential Revision: https://phabricator.services.mozilla.com/D6829
--HG--
extra : moz-landing-system : lando
To use this (Windows/Linux instructions), press Ctrl+L to give focus to the location bar. Shift+Tab to move focus backwards to the tab.
Ctrl+Left/Ctrl+Right to change which tab is focused
Ctrl+Space to add/remove a tab from the multiselection
Moving a tab has been changed from Ctrl+Left/Ctrl+Right to Ctrl+Shift+Left/Ctrl+Shift+Right, respectively.
Differential Revision: https://phabricator.services.mozilla.com/D4670
--HG--
extra : moz-landing-system : lando
Pages that are whitelisted for displaying on about:about can be
autocompleted in the URL bar.
MozReview-Commit-ID: BYhWUImyiJH
Differential Revision: https://phabricator.services.mozilla.com/D3072
--HG--
extra : moz-landing-system : lando
We need this because the AsyncTabSwitcher is responsible for switching between the
remote browser tab panels asynchronously. Asynchronous mode for the tabpanels
binding delegates the responsibility of actually changing the index of the
underlying deck to someone else (AsyncTabSwitcher, in this case).
Differential Revision: https://phabricator.services.mozilla.com/D6184
--HG--
extra : moz-landing-system : lando
Migrates strings from aboutUrlClassifier.dtd and aboutUrlClassifier.properties files to aboutUrlClassifier.ftl
Modifies aboutUrlClassifier.xhtml and aboutUrlClassifier.js to use fluent.
Differential Revision: https://phabricator.services.mozilla.com/D5156
--HG--
extra : moz-landing-system : lando
This is a regression left over by Bug 1431255 Part IV.
I did s/anonid/id/ in videocontrols.js but I didn't do that in CSS.
anonid selectors are still needed in CSS until we remove the XBL binding.
Depends on D3667
Differential Revision: https://phabricator.services.mozilla.com/D3840
--HG--
extra : moz-landing-system : lando
The UA Widget videocontrols is contained in a <div class="videocontrols">
instead of an <xul:videocontrols>.
The former is by default visible in the accessibility tree unless its
role is set to none.
Depends on D3665
Differential Revision: https://phabricator.services.mozilla.com/D3666
--HG--
extra : moz-landing-system : lando
We need this because the AsyncTabSwitcher is responsible for switching between the
remote browser tab panels asynchronously. Asynchronous mode for the tabpanels
binding delegates the responsibility of actually changing the index of the
underlying deck to someone else (AsyncTabSwitcher, in this case).
Differential Revision: https://phabricator.services.mozilla.com/D6184
--HG--
extra : moz-landing-system : lando
This prevents an exception in browser.xhtml when there's no head, since
it's currently sharing the markup with browser.xul.
Differential Revision: https://phabricator.services.mozilla.com/D6194
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
When screen readers speak the button and subsequent menu when it pops up, the current full prompt is spoken by screen readers. This patch adds a localizable string that is spoken for both instances instead, but it not being displayed visually. This streamlines and improves the screen reader experience for this control and its menu popup a lot.
Differential Revision: https://phabricator.services.mozilla.com/D5999
--HG--
extra : moz-landing-system : lando
To use this (Windows/Linux instructions), press Ctrl+L to give focus to the location bar. Shift+Tab to move focus backwards to the tab.
Ctrl+Left/Ctrl+Right to change which tab is focused
Ctrl+Space to add/remove a tab from the multiselection
Moving a tab has been changed from Ctrl+Left/Ctrl+Right to Ctrl+Shift+Left/Ctrl+Shift+Right, respectively.
Differential Revision: https://phabricator.services.mozilla.com/D4670
--HG--
extra : moz-landing-system : lando
Remove the _manifestURI field and handling of the MozApplicationManifest message.
Differential Revision: https://phabricator.services.mozilla.com/D5336
--HG--
extra : rebase_source : 352630ba837a27c00ed0fbba1df1ace91f7119d3
This is a follow up to Bug 1482667. The list of callers was gathered by instrumenting
the webidl calls to these methods and dumping JS stack when they are called in browser.xul.
Differential Revision: https://phabricator.services.mozilla.com/D5185
--HG--
extra : moz-landing-system : lando
Bug 1008772 moved all key handlers related to browser tabs to the system group to prevent websites from stealing tab switching keys.
However, this is only necessary for global tab switching keys; e.g. Control+Tab, Control+PageUp.
It is not necessary for keys which only operate when the tab bar is focused; e.g. Up/DownArrow.
This is because when the browser chrome is focused (including the tab bar), content key handlers can't intercept key presses.
Furthermore, having these in the system group gives them precedence over XUL context menus.
This causes tab switches to occur when the arrow keys are pressed while the context menu is open, which is highly undesirable.
Moving these (non-global) keydown handlers into the normal group fixes this.
Differential Revision: https://phabricator.services.mozilla.com/D4854
--HG--
extra : moz-landing-system : lando
Automatic changes by ESLint, except for manual corrections for .xml files.
Differential Revision: https://phabricator.services.mozilla.com/D4439
--HG--
extra : moz-landing-system : lando
On macOS, access keys are not visually observable.
On Linux and Windows, access keys are underlined.
Moreover, if intl.menuitems.alwaysappendaccesskeys is set, the access
key is always appended as "(X)", optionally preceded by a space, where X
is the uppercased version of the access key.
This commit updates the logic to not append a new "(X)" if this expected
suffix is already present at the end of the label.
Differential Revision: https://phabricator.services.mozilla.com/D3996
--HG--
extra : moz-landing-system : lando
The "menu-button" notification button type is unused, and the "menu" type is implemented using a normal button that opens a popup.
Differential Revision: https://phabricator.services.mozilla.com/D4530
--HG--
extra : rebase_source : b662ec12f98bbb6841aaf4682393bb0e29830e73
Since videocontrols run in content, this is generally a content privileged HTML
document which doesn't have access to that API. And besides, we actually want
this to be an <html:button>.
The "select" event handler workaround was originally added in bug 1379270 to make it
possible to focus and select the URL bar a little bit later. This ugly hack was to
workaround an issue with WebExtensions that override about:newtab with the
chrome_url_overrides property (the issue would be that the URL bar would not be
properly focused and selected if about:newtab was overridden).
Back in the day, this was necessary because the overriding URL was fully displayed
in the URL bar (moz-webextension://...). These days, when about:newtab is overridden,
the URL bar is still empty - we just end up showing the information about the
WebExtension overriding about:newtab to the left of the URL bar.
So I think we can remove the old workaround.
Differential Revision: https://phabricator.services.mozilla.com/D3447
--HG--
extra : moz-landing-system : lando
For some reason we might miss the initial focus event. This ensures the video
element is focused when the document loads.
Differential Revision: https://phabricator.services.mozilla.com/D3444
--HG--
extra : moz-landing-system : lando
Summary:
Mike DeBoer correctly noted in a comment at https://bugzilla.mozilla.org/show_bug.cgi?id=254592 that enabletimeout is no longer used and should be removed. I updated the timeout logic to treat a zero or negative value as effectively "no automatic timeout" for the quick-find dialog (otherwise, setting the timeout value to a small or negative value makes the feature unusable).
This is a corollary to the bugfix at https://phabricator.services.mozilla.com/D3404 ; I've split it out into a separate patch to avoid confusing that issue.
Update: this specific issue already had its own bug at https://bugzilla.mozilla.org/show_bug.cgi?id=260562, and another mention at https://bugzilla.mozilla.org/show_bug.cgi?id=265915 .
Reviewers: kmag
Reviewed By: kmag
Bug #: 260562
Differential Revision: https://phabricator.services.mozilla.com/D3504
--HG--
extra : rebase_source : 1c2b73d6af1343d536a2380dee784f8ea2339b61
extra : amend_source : cc00a2398b2c478003e842b4dc9b99bf53af6824
This crash happens because nsVideoFrame didn't know what to do with two
children in the UA Widget Shadow Root.
The two children are both videocontrols, with the first one being the lingering
DOM inserted by first constructor call that throws.
The subsequent appendChild of the same element caused the videocontrols
to be initialized again, since the previous run didn't return a widget
instance to UAWidgetsChild.
The fix here removes the throw statement added in
https://hg.mozilla.org/mozilla-central/rev/dca187f7c72c#l3.15 ,
allowing the constructor to complete.
Without this statement, we will rely on assertion in the test here
https://hg.mozilla.org/mozilla-central/rev/4ddca5eb06c2#l2.18
to fail on slower platforms to ensure the stylesheet is loaded synchronously.
An alternative fix would be to wrap up the contructor in a try catch block
from UAWidgetsChild and make sure the DOM is cleaned up when the constructor
throw. That however will hide the error thrown so I decided to remove the throw
statement instead.
Differential Revision: https://phabricator.services.mozilla.com/D3560
--HG--
extra : moz-landing-system : lando
Set SheetLoadData::mSyncLoad to true when the link element is in a UA Widget.
MozReview-Commit-ID: 2NPSJnL0rKl
--HG--
extra : rebase_source : 9af8c7add41b39f6eb8e3ac02dbefb9607b905f9
For elements with an animationProp, always set its hidden state from the
startFade() method, so the reverse-direction animation can be correctly
cancelled.
Additionally, considers elements with "fadeout" class as hidden,
so other states can be toggled correctly.
This patch fixes intermittent failures on slower platforms, and perma-orange
on Windows.
MozReview-Commit-ID: KgQXaryEHad
--HG--
extra : rebase_source : b2c7eb81110bf2a55820460cfc24b3418fd4bbdb
Also removing unremoved <xul:slider> properties and workarounds.
MozReview-Commit-ID: 8JrcDyDOBWS
--HG--
extra : rebase_source : ebd8c3af91d07769ab2d71e8ac9be541e7fae68f
This is documented throughly in bug 448909 comment 79.
It is no longer needed for our current setup.
MozReview-Commit-ID: 9XWCqGUYHW4
--HG--
extra : rebase_source : 7d8e042d2e11704b68fb42ea14b421d9eada4abb
Acknowledge the control bar hidden behavior caused by the bug.
Also, set the cursor state before early return, because the video might not
be in the same fullsreen state the last time control bar is hidden/shown.
MozReview-Commit-ID: 3oN3r8dsUvH
--HG--
extra : rebase_source : 34a95e9d5ddfd8abb96adde452858e4b7acb4946
The DOM elements within the UA Widget Shadow DOM should have its reflectors in
the UA Widget Scope. This is done by calling nsINode::IsInUAWidget() which
would check its containing shadow and its UA Widget bit.
To prevent JS access of the DOM element before it is in the
UA Widget Shadom DOM tree, various DOM methods are set to inaccessible to
UA Widget script. It would need to use the two special methods in ShadowRoot
instead to insert the DOM directly into the shadow tree.
MozReview-Commit-ID: Jz9iCaVIoij
--HG--
extra : rebase_source : b7b17be68dcde00cfeb207cb39cf16b486f2ab02
videocontrols.js handles the controls attribute with a callback named
"onattributechange" called by UAWidgets, replaces the CSS selectors.
MozReview-Commit-ID: 8rrw0Pbu8Dj
--HG--
rename : toolkit/content/widgets/videocontrols.xml => toolkit/content/widgets/videocontrols.js
extra : rebase_source : 8d8a38afac0273621f711b988c1be82d04865e33
Browsers can switch at runtime from remote to non-remote and vice versa,
which on the C++ side is detected from a XBL binding change which causes
nsIRemoteBrowser to either be implemented or not. Custom Elements can't
change at runtime in the same way, so unifying on a single [implements]
will allow browser (both remote and non-remote) to be migrated to a single
Custom Element.
To keep current functionality, this updates Qi calls into nsIRemoteBrowser
to instead Qi into nsIBrowser and check isRemoteBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D3346
--HG--
extra : moz-landing-system : lando
Adds a new environment variable MOZ_BROWSER_XHTML to change Firefox to load
a modified version of browser.xul as browser.xhtml. Adds the xhtml
namespace to the script tags to make them work.
MozReview-Commit-ID: 2adtOVzXHKd