This is part 3 of implementing the Wasm BigInt<>I64 conversion proposal for inlined Ion to Wasm calls.
This part adds changes needed in code generation and Wasm stubs for supporting the I64 arguments for
inlined Ion to Wasm calls.
Differential Revision: https://phabricator.services.mozilla.com/D65236
Importing security.h introduced namespace collisions so I removed the `using namespace mozilla;` and replaced it with specific names.
Differential Revision: https://phabricator.services.mozilla.com/D72422
The information comes with SetDisplayList messages but was applied before scene building instead of during scene swap, which breaks the transaction model and looks like a bug.
Differential Revision: https://phabricator.services.mozilla.com/D71934
On older machines it creates a blank window and we only need the pref to direct manipulation (which hasn't landed yet and will be preffed off by default when it lands).
Differential Revision: https://phabricator.services.mozilla.com/D72283
In this patch we add a new resource type for page errors.
We don't do anything specific for CSS Warnings yet, as they're going
to be handled as part of Bug 1625910.
A test is added (following devtools/shared/webconsole/test/chrome/test_page_errors.html
as an example).
A couple function that were used for the console-messages test
are moved into head.js as they're also used in the error-message test.
Differential Revision: https://phabricator.services.mozilla.com/D71955
Doing this in the ship phase instead of push lets us avoid shipping on
flathub before the actual release.
And, upload flatpaks for firefox release candidates to flathub's "beta"
channel so we can get feedback on them and QA can also get at them.
Differential Revision: https://phabricator.services.mozilla.com/D71919
This is what I see when running the test:
console.log: Changing zoom for browser from 1 to 0.5
set fullZoom@chrome://global/content/elements/browser-custom-element.js:812:19
set fullZoom@chrome://browser/content/tabbrowser.js:526:7
ZoomManager_setZoomForBrowser@chrome://global/content/viewZoomOverlay.js:60:7
set zoom@chrome://global/content/viewZoomOverlay.js:49:10
@chrome://mochitests/content/browser/browser/components/customizableui/test/browser_947914_button_zoomReset.js:26:5
Async*Tester_execTest/<@chrome://mochikit/content/browser-test.js:1039:34
Tester_execTest@chrome://mochikit/content/browser-test.js:1074:11
nextTest/<@chrome://mochikit/content/browser-test.js:904:14
SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:918:23
"FullZoomChange for browser"
PASS Zoom reset button exists in Panel Menu -
console.log: Changing zoom for browser from 0.5 to 1
console.log: set fullZoom@chrome://global/content/elements/browser-custom-element.js:817:19
ZoomManager_setZoomForBrowser@chrome://global/content/viewZoomOverlay.js:60:7
FullZoom__applyPrefToZoom@chrome://browser/content/browser-fullZoom.js:479:19
FullZoom_onLocationChange@chrome://browser/content/browser-fullZoom.js:247:14
XWB_onUpdateCurrentBrowser@chrome://browser/content/browser.js:5419:16
callListeners@chrome://browser/content/tabbrowser.js:820:31
_callProgressListeners@chrome://browser/content/tabbrowser.js:834:22
_callProgressListeners@chrome://browser/content/tabbrowser.js:5776:46
onStateChange@chrome://browser/content/tabbrowser.js:6039:14
_callProgressListeners@resource://gre/modules/RemoteWebProgress.jsm:75:31
onStateChange@resource://gre/modules/RemoteWebProgress.jsm:88:10
Which is pretty broken (the zoom is reset way earlier than clicking the reset
button, by FullZoom.onLocationChange).
This seems to me was mostly passing by chance, but with my Fission changes
which made FullZoomChange events more async (and actually, not notify twice) it
started failing.
Wait to load a page before changing the zoom level so that the browser doesn't
reset it when navigating.
Differential Revision: https://phabricator.services.mozilla.com/D72208
This way, something like:
*:where(.foo, .bar)
Will end up twice on the selector map, just as if you would've written
.foo, .bar.
But we're a bit careful to not be wasteful, so:
.foo:where(div, span)
Will still end up using the .foo bucket.
It needs a bit of borrow-checker gymnastics to avoid cloning the entry
in the common path. It's a bit gross but not too terrible I think.
Differential Revision: https://phabricator.services.mozilla.com/D71457
There are a bunch of missing tests, and there are some tests that don't
match the current spec text, that I need to write or fix before I enable the
feature everywhere.
But there are fairly complex invalidation tests, that we pass flawlessly :)
Differential Revision: https://phabricator.services.mozilla.com/D71424
See the comment about why this is valuable. For a selector like:
.foo:is(.bar) > .baz
Before this patch we'd generate an Dependency for .bar like this:
Dependency {
selector: .bar,
offset: 0,
parent: Some(Dependency {
selector: .foo:is(.bar) > .baz,
offset: 1, // Pointing to the `>` combinator.
parent: None,
}),
}
After this patch we'd generate just:
Dependency {
selector: .foo:is(.bar) > .baz,
offset: 1, // Pointing to the `>` combinator.
parent: None,
}
This is not only less memory but also less work. The reason for that is that,
before this patch, when .bar changes, we'd look the dependency, and see there's
a parent, and then scan that, so we'd match `.bar` two times, one for the
initial dependency, and one for .foo:is(.bar).
Instead, with this we'd only check `.foo:is(.bar)` once.
Differential Revision: https://phabricator.services.mozilla.com/D71423
That way we can look at the parent dependency as described in the previous
patch. An alternative would be to add a:
parent_dependency: Option<&'a Dependency>
on construction to `Invalidation`, but this way seems slightly better to avoid
growing the struct. It's not even one more indirection because the selector is
contained directly in the Dependency struct.
Differential Revision: https://phabricator.services.mozilla.com/D71422
The tricky part of :is() and :where() is that they can have combinators inside,
so something like this is valid:
foo:is(#bar > .baz) ~ taz
The current invalidation logic is based on the assumption that you can
represent a combinator as a (selector, offset) tuple, which are stored in the
Dependency struct. This assumption breaks with :is() and :where(), so we need
to make them be able to represent a combinator in an "inner" selector.
For this purpose, we add a `parent` dependency. With it, when invalidating
inside the `:is()` we can represent combinators inside as a stack.
The basic idea is that, for the example above, when an id of "bar" is added or
removed, we'd find a dependency like:
Dependency {
selector: #bar > .baz,
offset: 1, // pointing to the `>` combinator
parent: Some(Dependency {
selector: foo:is(#bar > .baz) > taz,
offset: 1, // Pointing to the `~` combinator.
parent: None,
})
}
That way, we'd start matching at the element that changed, towards the right,
and if we find an element that matches .baz, instead of invalidating that
element, we'd look at the parent dependency, then double-check that the whole
left-hand-side of the selector (foo:is(#bar > .baz)) actually changed, and then
keep invalidating to the right using the parent dependency as usual.
This patch only builds the data structure and keeps the code compiling, the
actual invalidation work will come in a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D71421
