In some edge cases, we may start handling user input events that
are not supposed to be handled by the current document.
This patch introduces some delay to handle user input events.
Differential Revision: https://phabricator.services.mozilla.com/D180976
This one is tricky because form controls, though I think I got it right...
This fixes a pre-existing bug where we're not following the spec for readonly
inside content-editable.
I filed this as bug 1850390 but other browsers match the spec so add a test and
fix it while at it. This allows cheaper checks for readonlyness in a couple
places.
Differential Revision: https://phabricator.services.mozilla.com/D186896
Our counters are super low because we report lots of empty entries for
these. It seems just opening a new tab is enough to trigger this.
While at it I found that we also report about:preferences / about:config
since they use the system principal. Also block those.
Differential Revision: https://phabricator.services.mozilla.com/D184834
In some edge cases, we may start handling user input events that
are not supposed to be handled by the current document.
This patch introduces some delay to handle user input events.
Differential Revision: https://phabricator.services.mozilla.com/D180976
This probably should have been done earlier, but became obvious with uses of Document::HasStorageAccessPermissionGrated in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D184825
Because the Document's Channel's LoadInfo is no longer being set to reflect the storage-access permission, we need to test if the permission is set before we ask the user about it.
Currently I opted for an IPC (and one we already have) in Fission. We could cut this out with an extra bit on the document, but I don't think this is performance-critical since it only happens on prompt-able requestStorageAccess calls.
Differential Revision: https://phabricator.services.mozilla.com/D184824
Our counters are super low because we report lots of empty entries for
these. It seems just opening a new tab is enough to trigger this.
While at it I found that we also report about:preferences / about:config
since they use the system principal. Also block those.
Differential Revision: https://phabricator.services.mozilla.com/D184834
This probably should have been done earlier, but became obvious with uses of Document::HasStorageAccessPermissionGrated in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D184825
Because the Document's Channel's LoadInfo is no longer being set to reflect the storage-access permission, we need to test if the permission is set before we ask the user about it.
Currently I opted for an IPC (and one we already have) in Fission. We could cut this out with an extra bit on the document, but I don't think this is performance-critical since it only happens on prompt-able requestStorageAccess calls.
Differential Revision: https://phabricator.services.mozilla.com/D184824
This new event will be consumed by DevTools to update style information.
As for `StyleSheetApplicableStateChanged`, this event is emitted from the document.
It's only enabled when `document.styleSheetChangeEventsEnabled` is set to true.
The existing test around the `StyleSheetApplicableStateChanged` is renamed and
modified to assert both events when stylesheets are added, modified and removed.
Differential Revision: https://phabricator.services.mozilla.com/D147271
The subdocument call when there's no root frame is silly, because we
won't find a canvas frame and we'll end up with transparent.
This needs to tweak the canvas frame construction code to make canvas
anon content show up on the "top" canvas, not on the page content
canvas.
This can be simplified now, because the reason we had to build canvas
anon content before processing kids of the root frame (bug 1558352) no
longer applies since I made popups regular out-of-flow elements
(bug 1799343).
Differential Revision: https://phabricator.services.mozilla.com/D179461
Right now, when binding to the tree we queue a runnable to update the
stylesheet, even though mEnableUpdates is false.
Even though the redundant update is nowadays always cached, it's just
wasted work, and the code is simpler without it.
This will be tested by bug 1771113, which is what made me look at this.
We need to tweak a bit the dispatch of applicable state change events
for DevTools, because for a case like:
div.attachShadow({ mode: "open" }).innerHTML = `<style>...</style>`;
Before we'd go through the stylesheet cache here due to the redundant
update:
https://searchfox.org/mozilla-central/rev/fb43eb3bdf5b51000bc7dfe3474cbe56ca2ab63c/layout/style/SharedStyleSheetCache.cpp#161-165
But now we won't, and the code in StyleSheet.cpp wasn't quite correct /
didn't dispatch the event.
Nobody listens to style-sheet-applicable-state-changed, so remove that
code while at it.
Differential Revision: https://phabricator.services.mozilla.com/D185559
