In CJK locales, line break could happen in any letter of the button. The fix here is to explicitly specify flex property so that the button couldn't grow or shrink.
Differential Revision: https://phabricator.services.mozilla.com/D79823
This was previously r=jchen and landed, but was backed out because some
Android tests were running on an unrealistically old Linux kernel. These
tests have been retired, so this can reland.
Differential Revision: https://phabricator.services.mozilla.com/D81278
Bug 1486524 disabled the features from the custom linker that required
AutoObjectMapperFaultyLib. We can now rely on AutoObjectMapperPOSIX
instead.
Differential Revision: https://phabricator.services.mozilla.com/D81264
In various parts of the picture and mask code, we were casting
the `clipped` rect to i32 (after rounding out). However, this
can cause overflow panics when the origin of the rect is too big.
Instead, treat the origin as f32 (which it was generally being
converted to anyway), and only cast the size part to be i32 as
required. This is safe since we know that the size has been
clipped to the visible screen, so will always be safe to cast
to i32.
Differential Revision: https://phabricator.services.mozilla.com/D80968
When we call into LoadSheet when starting pending loads for a given
loader, it may be the case that the original loader may still not care
about the load. However some other loader will, so we can't defer this.
This was also causing our state to get out of sync, because if this
happened, then we'd fail to account for it in other loaders.
Differential Revision: https://phabricator.services.mozilla.com/D81119
Some of the testing info is from the Oxidation wiki, and the logging info is
largely from a dev-platform email by Valentin. The other parts I wrote from
scratch.
The commit also makes some small improvements to the Rust build docs.
Differential Revision: https://phabricator.services.mozilla.com/D81017
The code already explicitly checks for and handles the rect here
having a zero or invalid size, there is no need to assert that
the rect size itself is valid.
Differential Revision: https://phabricator.services.mozilla.com/D81249
* ctrl+d: Dump DOM tree (content). (Use "d" because "c" is for copy.)
* ctrl+f: Dump frame trees.
* ctrl+p: Dump frame trees in CSS pixels.
On macOS, the modified is cmd instead of ctrl.
Differential Revision: https://phabricator.services.mozilla.com/D81234
I will admit from the start that this patch is goofy and is not the "proper" fix.
If you're unlucky enough to tickle the current unification in `dom/media`, then there's a conflict between `namespace mozilla::details` of `SPSCQueue.h` and `namespace details` of Chromium's `task.h`. Ultimately, the badness stems from some unified file doing `using namespace mozilla;`, but I'm really not enthusiastic about reworking that when I just want to get unblocked.
I'm going to attempt to justify the yuckiness of this patch on the basis that:
* `SPSCQueue.h` is super self-contained and rarely looked at, I bet nobody will notice this change
* Tons of other code prefers the spelling `mozilla::detail` anyway
Differential Revision: https://phabricator.services.mozilla.com/D81162
This switches the `nsIContent{Parent,Child}` interface to be
`nsIDOMProcess{Parent,Child}`, and also implements it on
`InProcess{Parent,Child}`, along with the `ProcessActor` interface.
Differential Revision: https://phabricator.services.mozilla.com/D80582
This moves it near the cross-process `PContent` actor, and makes it more clear
that this actor is only intended to be used for DOM things.
Differential Revision: https://phabricator.services.mozilla.com/D80581
The WPT a-download-click-404.html requires this behaviour for links with the download attribute, and this is also the current behaviour for Content-Disposition: Attachment (see bug 1604308).
This previously worked because the parent process version of nsDocumentOpenInfo failed (with NS_ERROR_FILE_NOT_FOUND), but the error code was discarded and we forwarded the channel to the content process. The content process version then would then return NS_ERROR_WONT_HANDLE_CONTENT since the load requires downloading, but we don't allow that in the content process. This new error code is one that doesn't have an associated error page (unlilke the original error), so was silently discarded.
Differential Revision: https://phabricator.services.mozilla.com/D81014