- Add Synchronous version of HasStorageAccess
- Use this synchronous version as an additional way to be granted the StorageAccessAPI permission on user interaction
- Test that storageAccessAPI permission is granted on user interaction
Differential Revision: https://phabricator.services.mozilla.com/D132024
Use the same document state mechanism we have for :moz-locale-dir. Also,
simplify the setup of the later to be the same as :dir(), allowing the
matching code to be less repetitive.
This should fix some flakiness in chrome mochitests, but we have no existing
tests for these pseudo-classes more generally and since they're just
chrome-only I'm not super-excited about adding more.
Differential Revision: https://phabricator.services.mozilla.com/D130735
I added an option to return also the nodes because it's very helpful for
debugging. A bunch of the "unknown" ones are just elements with
transparent backgrounds (but still hit-testable), so we probably want to
exclude them from the result list or what not to massively reduce the
size of the returned object.
But anyhow, this probably does for a prototype.
Differential Revision: https://phabricator.services.mozilla.com/D128720
Remove the follow-firefox-theme pref as now that's default everywhere,
and document better the behavior of the color-scheme property by
reworking and commenting the logic on it a bit.
Differential Revision: https://phabricator.services.mozilla.com/D128610
This shouldn't change behavior, but I find it a bit easier to reason
about (and should be marginally faster by not doing double attribute
lookups, but not like the should usually matter).
Differential Revision: https://phabricator.services.mozilla.com/D128389
This shouldn't change behavior, but I find it a bit easier to reason
about (and should be marginally faster by not doing double attribute
lookups, but not like the should usually matter).
Differential Revision: https://phabricator.services.mozilla.com/D128389
This patch changes the way how we decide to expose the privilege SSA to
document interface. We will expose the interface for system principal
and the content script of the webcompat extension only.
Differential Revision: https://phabricator.services.mozilla.com/D125959
Unsuppressing is done only if the page can use stylesheet cache. That should mean the
load isn't a cold load and also some other resources may be cached and thus
painting could happen sooner.
There is currently a regression around dom.ipc.processCount.webIsolated handling, but the
testing has been done with dom.ipc.processCount.webIsolated==1, and the patch for bug 1731792
should give back similar behavior as what process count 1 has.
Differential Revision: https://phabricator.services.mozilla.com/D125878
Priviously, the ContentBlocking::ShouldAllowAccessFor() checkes don't
check if the storage permission was came from the allowList or not. This
patch changes that and it will check if the channel/window is
allowlisted at the same moment as checking the ContentBlockingAllowList.
It returns early if the channel/window is in the allowList.
Differential Revision: https://phabricator.services.mozilla.com/D126278
This version doesn't change SetContainer handling, since it seems to be tricky for the top level page.
So only activity change notification is fired and IsActive() is updated.
The comment about IsActive() was wrong even with the old bfcache implementation.
(I did check that it returned false when the page was in bfcache and many of the activity observers rely on that)
The changes to HTMLMediaElement are needed to ensure page can enter bfcache..
Differential Revision: https://phabricator.services.mozilla.com/D124684
I have no idea how to make the test result stable because the intermittent
failure is caused by a race of `IMEContentObserver`'s content query performend
at vsync and `keypress` event after the `keydown` event. Therefore, I try to
fix the root cause of the failure.
There are two paths reaching a public method of editor with pending
notifications. One is `keypress` event listener of the editor. The other is
`execCommand` related methods of `Document`. Therefore, we should make them
flush pending notifications before accessing editor, but the cost may be too
expensive. So we should consider whether we should flush pending notifications
or not as far as later.
Note that we cannot fix the `beforeinput` cases because flushing pending
notifications after dispatching `beforeinput` event may cause oranges. It'll
be fixed while I'm working on bug 1710784.
Differential Revision: https://phabricator.services.mozilla.com/D125805
SetContainer handling is similar to what DocumentViewer does for the old bfcache implementation.
(The old implementation hides it quite well).
The changes to HTMLMediaElement are needed to ensure page can enter bfcache.
Removed erroneous MOZ_ASSERT in nsPresContext, it is ok to trigger that code path in the new implementation.
And the Run() method of the relevant nsIRunnable already deals with that case.
Differential Revision: https://phabricator.services.mozilla.com/D124684
The test is in theory racy, but trying to limit the cases when it might behave badly
by running it on opt desktop builds only. Without the patch the 'period' check takes over 400ms locally and with the
patch 1-3ms.
The changes are just trying to optimize execution, not change the behavior.
Use of SuppressedMicroTasks is perhaps a bit odd, but it helps keeping
SavedMicroTaskQueue and similar code simple.
Differential Revision: https://phabricator.services.mozilla.com/D122290
Benjamin VanderSloot
Emilio Cobos Álvarez
Sandor Molnar
Butkovits Atila
Kagami Sascha Rosylight
Paul Zuehlcke
olaoluwa
Sean Feng
Tim Huang
Olli Pettay
owlishDeveloper
Noemi Erli
Tooru Fujisawa
Masayuki Nakano
Mirko Brodesser
Peter Van der Beken
Sebastian Hengst
Zibi Braniecki