Bug 1489040 - P1 - Update WebRTC ICE candidate stats field ipAddress to new name, address
Bug 1489040 - P2 - adjust WebRTC stats mochitest for new stat name 'address'
Bug 1489040 - P3 - add test for legacy WebRTC stat names
Differential Revision: https://phabricator.services.mozilla.com/D5560
--HG--
extra : moz-landing-system : lando
Previously, if the accesskey attribute was missing then the label would reach up
to binding parent to find it's accesskey. In practice, bindings already do
[xbl:inherits=accesskey] to send it down to the label anyway.
The problem with this is that for controls without accesskeys, the attribute doesn't get set,
so the label will access the control from JS. This is fine for XBL, since typically
the label XBL will construct at the same time as the control, but when migrating
to Custom Elements, the label gets connected even when the control is hidden.
Differential Revision: https://phabricator.services.mozilla.com/D12355
--HG--
extra : moz-landing-system : lando
Currently, some "input" event dispatchers in our script dispatch "input" event
with UIEvent. This is completely wrong. For conforming to HTML spec, Event
is proper event. Additionally, for conforming to Input Events, InputEvent
is proper event only on <textarea> or <input> element which has a single line
editor.
For making us to maintain easier, this patch adds new API, "isInputEventTarget"
to MozEditableElement which returns true when "input" event dispatcher should
use InputEvent for the input element.
Finally, this makes some dispatchers use setUserInput() instead of
setting value and dispatching event by themselves. This also makes
us to maintain them easier.
Note that this does not touch "input" event dispatchers which dispatch events
only for chrome (such as URL bar, some pages in about: scheme) for making
this change safer as far as possible.
Differential Revision: https://phabricator.services.mozilla.com/D12247
--HG--
extra : moz-landing-system : lando
When editor is modified as part of user action, aFlags of
nsTextEditorState::SetValue() includes eSetValue_BySetUserInput. In this case,
TextEditor (if there is) or the method itself (if there is no editor yet)
should dispatch "input" event by themselves because we will need to initialize
InputEvents more since we're going to implement Input Event specs.
Note that even with this patch, password field stops dispatching "input" event
with call of HTMLInputElement::SetUserInput(). This is caused by a hidden bug
of TextEditRules. This will be fixed in a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D12245
--HG--
extra : moz-landing-system : lando
Currently, a lot of code dispatch "input" event and some of them dispatch
"input" event with wrong interface and/or values. Therefore this patch
creates nsContentUtils::DispatchInputEvent() to make all of them dispatch
correct event.
Unfortunately, due to bug 1506439, we cannot set pointer to refcountable
classes of MOZ_CAN_RUN_SCRIPT method to nullptr. Therefore, this patch
creates temporary RefPtr<TextEditor> a lot even though it makes damage to
the performance if it's in a hot path.
This patch makes eEditorInput event dispatched with
InternalEditorInputEvent when "input" event should be dispatched with
dom::InputEvent. However, this patch uses WidgetEvent whose message is
eUnidentifiedEvent and setting WidgetEvent::mSpecifiedEventType to
nsGkAtoms::oninput when "input" event should be dispatched with
dom::Event because we need to keep that eEditorInput and
InternalEditorInputEvent are mapped each other.
Differential Revision: https://phabricator.services.mozilla.com/D12244
--HG--
extra : moz-landing-system : lando
It's difficult to create new test which checks "input" events caused by
all edit operations especially when text is inserted from our UI. Therefore,
this adds "input" event type checks into existing tests.
Additionally, this adds new test for MozEditableElement.setUserInput() whose
behavior needs to be fixed in this bug.
Currently, InputEvent interface should be used only on text controls or
contenteditable editor when dispatching "input" event.
https://w3c.github.io/input-events/#events-inputevents
You may feel odd to use different event interface for same "input" events.
However, other browsers also use InputEvent interface only in the cases. So,
we should follow them for now.
Differential Revision: https://phabricator.services.mozilla.com/D12243
--HG--
extra : moz-landing-system : lando
This patch moves the marquee bindings from xbl-marquee.xml to marquee.js and converts them to a UA Widget.
The contenteditable bindings are dropped, replaced with a styling rule that will fix the position of the scrolling text.
Inline styles have been moved to the stylesheet so usage of display: -moz-box can continue to be parsed.
test_bug840098.html is deleted because it is only valid under the context of in-content XBL bindings.
Differential Revision: https://phabricator.services.mozilla.com/D10385
--HG--
rename : layout/style/xbl-marquee/xbl-marquee.css => toolkit/content/widgets/marquee.css
rename : layout/style/xbl-marquee/xbl-marquee.xml => toolkit/content/widgets/marquee.js
extra : moz-landing-system : lando
This patch moves the marquee bindings from xbl-marquee.xml to marquee.js and converts them to a UA Widget.
The contenteditable bindings are dropped, replaced with a styling rule that will fix the position of the scrolling text.
Inline styles have been moved to the stylesheet so usage of display: -moz-box can continue to be parsed.
test_bug840098.html is deleted because it is only valid under the context of in-content XBL bindings.
Differential Revision: https://phabricator.services.mozilla.com/D10385
--HG--
rename : layout/style/xbl-marquee/xbl-marquee.css => toolkit/content/widgets/marquee.css
rename : layout/style/xbl-marquee/xbl-marquee.xml => toolkit/content/widgets/marquee.js
extra : moz-landing-system : lando
Previously, the tabindex attribute wasn't supported on non-control XUL elements at all.
The only way to make those focusable was to use -moz-user-focus: normal.
However, that caused the element to be included in the tab order; there was no way to make it focusable but not tabbable.
This can now be achieved using tabindex="-1".
This will primarily be useful for buttons on toolbars, which will be grouped under a single tab stop for efficiency.
For consistency, this also changes the behaviour of tabindex="-1" with -moz-user-focus: ignore on XUL controls.
Previously, -moz-user-focus: ignore would override tabindex="-1", making the element unfocusable.
Now, the tabindex attribute always overrides if explicitly specified.
Differential Revision: https://phabricator.services.mozilla.com/D12000
--HG--
extra : moz-landing-system : lando
It was almost identical to the toolkit version, only missing a [customizing=true]
check to prevent drag. Since Customization only happens in browser/ we are able
to replace the toolkit version with the CUI version, and then remove the CUI version.
The `#toolbar-menubar:not([autohide="true"])` selector will fall back to the
`toolbar[type="menubar"]` selector in global.css to apply the toolkit one, so
that is removed from browser.css.
Differential Revision: https://phabricator.services.mozilla.com/D12146
--HG--
extra : moz-landing-system : lando
Removing the inner field while focused nulls out the active element, without a
blur event of course, so this means that we left the :focus state in the input
set incorrectly, plus that we actually lost focus.
Differential Revision: https://phabricator.services.mozilla.com/D12106
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
This patch removes the dom.webcomponents.shadowdom.enabled pref and all its
references, including the following functions:
* nsContentUtils::IsShadowDOMEnabled()
* nsIDocument::IsShadowDOMEnabled()
* nsDocument::IsShadowDOMEnabled(JSContext* aCx, JSObject* aGlobal)
* nsDocument::IsShadowDOMEnabled(const nsINode* aNode)
* nsTextNode::IsShadowDOMEnabled(JSContext* aCx, JSObject* aObject)
This function is renamed and updated to nsDocument::IsCallerChromeOrAddon():
* nsDocument::IsShadowDOMEnabledAndCallerIsChromeOrAddon(JSContext* aCx, JSObject* aObject)
I didn't change the tests that load Shadow DOM tests in an iframe, in the interest of keeping hg annotation history.
Differential Revision: https://phabricator.services.mozilla.com/D11183
--HG--
extra : moz-landing-system : lando
Part I of bug 1496242 was not implemented correctly as it accesses the
nsIDateTimeInputArea methods directly on the <datetimebox> element object.
This won't work because the XBL binding is run in a non-chrome scope.
The methods it implemented are exposed thus had to be accessed via
wrappedJSObject.
Object pass to setValueFromPicker() therefore has to clone into the content scope.
We can be sure that the methods called are implemented by the XBL binding,
because the web content should not have access to <datetimebox>, which is a NAC.
A small clean-up is included in the patch also, removing the useless 3rd argument
to the CustomEvent constructor.
Tests related to the datetime input is duplicated and run with UA Widget disabled
to ensure the XBL binding continue to work.
Differential Revision: https://phabricator.services.mozilla.com/D10947
--HG--
rename : dom/html/test/forms/chrome.ini => dom/html/test/forms/xbl/chrome.ini
rename : dom/html/test/forms/mochitest.ini => dom/html/test/forms/xbl/mochitest.ini
rename : dom/html/test/forms/test_autocompleteinfo.html => dom/html/test/forms/xbl/test_autocompleteinfo.html
rename : dom/html/test/forms/test_input_attributes_reflection.html => dom/html/test/forms/xbl/test_input_attributes_reflection.html
rename : dom/html/test/forms/test_input_date_bad_input.html => dom/html/test/forms/xbl/test_input_date_bad_input.html
rename : dom/html/test/forms/test_input_date_key_events.html => dom/html/test/forms/xbl/test_input_date_key_events.html
rename : dom/html/test/forms/test_input_datetime_focus_blur.html => dom/html/test/forms/xbl/test_input_datetime_focus_blur.html
rename : dom/html/test/forms/test_input_datetime_focus_blur_events.html => dom/html/test/forms/xbl/test_input_datetime_focus_blur_events.html
rename : dom/html/test/forms/test_input_datetime_focus_state.html => dom/html/test/forms/xbl/test_input_datetime_focus_state.html
rename : dom/html/test/forms/test_input_datetime_input_change_events.html => dom/html/test/forms/xbl/test_input_datetime_input_change_events.html
rename : dom/html/test/forms/test_input_datetime_tabindex.html => dom/html/test/forms/xbl/test_input_datetime_tabindex.html
rename : dom/html/test/forms/test_input_defaultValue.html => dom/html/test/forms/xbl/test_input_defaultValue.html
rename : dom/html/test/forms/test_input_sanitization.html => dom/html/test/forms/xbl/test_input_sanitization.html
rename : dom/html/test/forms/test_input_textarea_set_value_no_scroll.html => dom/html/test/forms/xbl/test_input_textarea_set_value_no_scroll.html
rename : dom/html/test/forms/test_input_time_key_events.html => dom/html/test/forms/xbl/test_input_time_key_events.html
rename : dom/html/test/forms/test_input_time_sec_millisec_field.html => dom/html/test/forms/xbl/test_input_time_sec_millisec_field.html
rename : dom/html/test/forms/test_input_types_pref.html => dom/html/test/forms/xbl/test_input_types_pref.html
rename : dom/html/test/forms/test_input_typing_sanitization.html => dom/html/test/forms/xbl/test_input_typing_sanitization.html
rename : dom/html/test/forms/test_label_input_controls.html => dom/html/test/forms/xbl/test_label_input_controls.html
rename : dom/html/test/forms/test_max_attribute.html => dom/html/test/forms/xbl/test_max_attribute.html
rename : dom/html/test/forms/test_min_attribute.html => dom/html/test/forms/xbl/test_min_attribute.html
rename : dom/html/test/forms/test_mozistextfield.html => dom/html/test/forms/xbl/test_mozistextfield.html
rename : dom/html/test/forms/test_novalidate_attribute.html => dom/html/test/forms/xbl/test_novalidate_attribute.html
rename : dom/html/test/forms/test_pattern_attribute.html => dom/html/test/forms/xbl/test_pattern_attribute.html
rename : dom/html/test/forms/test_required_attribute.html => dom/html/test/forms/xbl/test_required_attribute.html
rename : dom/html/test/forms/test_step_attribute.html => dom/html/test/forms/xbl/test_step_attribute.html
rename : dom/html/test/forms/test_stepup_stepdown.html => dom/html/test/forms/xbl/test_stepup_stepdown.html
rename : dom/html/test/forms/test_textarea_attributes_reflection.html => dom/html/test/forms/xbl/test_textarea_attributes_reflection.html
rename : dom/html/test/forms/test_validation.html => dom/html/test/forms/xbl/test_validation.html
rename : dom/html/test/forms/test_validation_not_in_doc.html => dom/html/test/forms/xbl/test_validation_not_in_doc.html
rename : dom/html/test/forms/test_valueAsDate_pref.html => dom/html/test/forms/xbl/test_valueAsDate_pref.html
rename : dom/html/test/forms/test_valueasdate_attribute.html => dom/html/test/forms/xbl/test_valueasdate_attribute.html
rename : dom/html/test/forms/test_valueasnumber_attribute.html => dom/html/test/forms/xbl/test_valueasnumber_attribute.html
rename : toolkit/content/tests/browser/browser_datetime_datepicker.js => toolkit/content/tests/browser/xbl/browser_datetime_datepicker.js
extra : moz-landing-system : lando
Part I of bug 1496242 was not implemented correctly as it accesses the
nsIDateTimeInputArea methods directly on the <datetimebox> element object.
This won't work because the XBL binding is run in a non-chrome scope.
The methods it implemented are exposed thus had to be accessed via
wrappedJSObject.
Object pass to setValueFromPicker() therefore has to clone into the content scope.
We can be sure that the methods called are implemented by the XBL binding,
because the web content should not have access to <datetimebox>, which is a NAC.
A small clean-up is included in the patch also, removing the useless 3rd argument
to the CustomEvent constructor.
Tests related to the datetime input is duplicated and run with UA Widget disabled
to ensure the XBL binding continue to work.
Differential Revision: https://phabricator.services.mozilla.com/D10947
--HG--
rename : dom/html/test/forms/chrome.ini => dom/html/test/forms/xbl/chrome.ini
rename : dom/html/test/forms/mochitest.ini => dom/html/test/forms/xbl/mochitest.ini
rename : dom/html/test/forms/test_autocompleteinfo.html => dom/html/test/forms/xbl/test_autocompleteinfo.html
rename : dom/html/test/forms/test_input_attributes_reflection.html => dom/html/test/forms/xbl/test_input_attributes_reflection.html
rename : dom/html/test/forms/test_input_date_bad_input.html => dom/html/test/forms/xbl/test_input_date_bad_input.html
rename : dom/html/test/forms/test_input_date_key_events.html => dom/html/test/forms/xbl/test_input_date_key_events.html
rename : dom/html/test/forms/test_input_datetime_focus_blur.html => dom/html/test/forms/xbl/test_input_datetime_focus_blur.html
rename : dom/html/test/forms/test_input_datetime_focus_blur_events.html => dom/html/test/forms/xbl/test_input_datetime_focus_blur_events.html
rename : dom/html/test/forms/test_input_datetime_focus_state.html => dom/html/test/forms/xbl/test_input_datetime_focus_state.html
rename : dom/html/test/forms/test_input_datetime_input_change_events.html => dom/html/test/forms/xbl/test_input_datetime_input_change_events.html
rename : dom/html/test/forms/test_input_datetime_tabindex.html => dom/html/test/forms/xbl/test_input_datetime_tabindex.html
rename : dom/html/test/forms/test_input_defaultValue.html => dom/html/test/forms/xbl/test_input_defaultValue.html
rename : dom/html/test/forms/test_input_sanitization.html => dom/html/test/forms/xbl/test_input_sanitization.html
rename : dom/html/test/forms/test_input_textarea_set_value_no_scroll.html => dom/html/test/forms/xbl/test_input_textarea_set_value_no_scroll.html
rename : dom/html/test/forms/test_input_time_key_events.html => dom/html/test/forms/xbl/test_input_time_key_events.html
rename : dom/html/test/forms/test_input_time_sec_millisec_field.html => dom/html/test/forms/xbl/test_input_time_sec_millisec_field.html
rename : dom/html/test/forms/test_input_types_pref.html => dom/html/test/forms/xbl/test_input_types_pref.html
rename : dom/html/test/forms/test_input_typing_sanitization.html => dom/html/test/forms/xbl/test_input_typing_sanitization.html
rename : dom/html/test/forms/test_label_input_controls.html => dom/html/test/forms/xbl/test_label_input_controls.html
rename : dom/html/test/forms/test_max_attribute.html => dom/html/test/forms/xbl/test_max_attribute.html
rename : dom/html/test/forms/test_min_attribute.html => dom/html/test/forms/xbl/test_min_attribute.html
rename : dom/html/test/forms/test_mozistextfield.html => dom/html/test/forms/xbl/test_mozistextfield.html
rename : dom/html/test/forms/test_novalidate_attribute.html => dom/html/test/forms/xbl/test_novalidate_attribute.html
rename : dom/html/test/forms/test_pattern_attribute.html => dom/html/test/forms/xbl/test_pattern_attribute.html
rename : dom/html/test/forms/test_required_attribute.html => dom/html/test/forms/xbl/test_required_attribute.html
rename : dom/html/test/forms/test_step_attribute.html => dom/html/test/forms/xbl/test_step_attribute.html
rename : dom/html/test/forms/test_stepup_stepdown.html => dom/html/test/forms/xbl/test_stepup_stepdown.html
rename : dom/html/test/forms/test_textarea_attributes_reflection.html => dom/html/test/forms/xbl/test_textarea_attributes_reflection.html
rename : dom/html/test/forms/test_validation.html => dom/html/test/forms/xbl/test_validation.html
rename : dom/html/test/forms/test_validation_not_in_doc.html => dom/html/test/forms/xbl/test_validation_not_in_doc.html
rename : dom/html/test/forms/test_valueAsDate_pref.html => dom/html/test/forms/xbl/test_valueAsDate_pref.html
rename : dom/html/test/forms/test_valueasdate_attribute.html => dom/html/test/forms/xbl/test_valueasdate_attribute.html
rename : dom/html/test/forms/test_valueasnumber_attribute.html => dom/html/test/forms/xbl/test_valueasnumber_attribute.html
rename : toolkit/content/tests/browser/browser_datetime_datepicker.js => toolkit/content/tests/browser/xbl/browser_datetime_datepicker.js
extra : moz-landing-system : lando
In Bug 1479125 we put calls to .children that were intended to access child elements into the custom
method, which is a slower path. We may eventually want to remove itemChildren altogether and just assume
that all children are items, but that's out of scope for a perf fix like this.
Differential Revision: https://phabricator.services.mozilla.com/D10751
--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
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