Contrary to setting no limit by default, we're giving it a reasonable
default size to prevent runaway memory usage when websites just keep
recording ad infinitum.
There are a few minor differences between this and Mozilla's implementation:
(a) The type error messages were not hardcoded to the Performance class and were moved to Errors.msg or domerr.msg instead.
(b) Resist fingerprinting-pref changes were skipped.
Partially based on https://bugzilla.mozilla.org/show_bug.cgi?id=1724645
There are a few minor differences between this and Mozilla's implementation:
(a) The type error messages were not hardcoded to the Performance class and were moved to Errors.msg instead.
(b) PerformanceMeasureOptions is used directly and doesn't use the the Maybe<> container class. I haven't found the reason yet, but PerformanceMeasureOptions is disallowed from having a copy constructor and without that, it isn't possible to use it with Maybe<>... There doesn't seem to be any problem with using it directly, though.
(c) Resist fingerprinting-pref changes were skipped.
Partially based on https://bugzilla.mozilla.org/show_bug.cgi?id=1762482
Currently, we dispatch keypress event when Enter is pressed without
modifiers or only with the Shift key (line break).
However, other browsers dispatch keypress events for Ctrl + Enter also
even if it doesn't cause any text input.
So, we should fire keypress events for Ctrl + Enter, even in strict
keypress dispatching mode. Note that with other modifiers, it depends on
the browser and/or platform and we can't dispatch the event for
consistent behavior.
This means web developers shouldn't rely one keypress events to catch
Alt + Enter, Meta + Enter and two or more modifiers + Enter.
Based on BZ 1438133
Resolves#2161
- Check against all selector parts and not the leftmost selector only for ::slotted()
- Walk rules for ::slotted() regardless if the shadow root is opened/closed
- Ensure that ::slotted() rules are walked in the right order
- Fix ::slotted inheritance from topmost shadow root
This is likely inefficient, but I haven't found a way other than this to ensure that the host frame is updated if the inserted/removed content isn't slotted. I'm assuming that Firefox is handling this somewhere else (and may have been even moved to Stylo), but was mentioned in an m-c bug we haven't seen yet. In fact, this is actually similar to how we handled elements passed to ContentInserted before landing e31ed5b07466d4a579fe4b025f97c971003fbc3f.
* Unlike the original patch, this does not remove the XPCOM version of Document.adoptNode/importNode to avoid breaking other applications that might be using those functions.
This covers the following:
Bug 1413834 Implement sequential focus navigation regarding shadow DOM
> Bug 1430020 Let sequential focus navigation in shadow DOM enter iframes
> Bug 1430701 Handle focus navigation on frameless shadow hosts in light DOM
> Bug 1430692 Handle focus navigation on NAC in shadow DOM
> Bug 1453693 Ensure sequential focus navigation works in Shadow DOM and add some tests
> Bug 1466581 Handle sequential focus also in nested shadow DOM
> Bug 1481079 Shadow DOM hosts should be focusable
> Bug 1507101 Use StyleChildrenIterator instead of custom frame tree walking code to handle NAC inside shadow dom
> Bug 1512043 Ensure traverse all nodes owned by the top level shadow host
> Bug 1512457 Fix various cases that focus navigation doesn't work well with frameless shadow host
> Bug 1513141 Really minor nsFocusManager cleanup
> Bug 1519090 Keyboard focus is trapped inside <slot>
> Bug 1528034 Make IsHostOrSlot null-safe
> Bug 1544826 Wrong focus navigation behavior when the root element is a shadow root
>> Bug 1500273 Ensure backward focus navigation works in Shadow DOM
