This version of the test passes for me locally with Osaka/Osaka-Mono installed, and also passes
(because both test and reference fall back to serif) if they're absent. It should fail only if
the Osaka family is present, but the Osaka-Mono family name (which is the special-case entry
that was broken) is not recognized.
Differential Revision: https://phabricator.services.mozilla.com/D109223
This is needed for bug 1700379, because otherwise we create a reference
frame with the root's scrolled content (the
::-moz-scrolled-page-sequence), and that breaks some display list
invariants.
Always create a canvas frame instead, (doesn't matter when printing
since we print off the page sequence frame directly), and create a
single ::-moz-page-sequence box.
We have to add width: 100% to the UA sheet because we don't get it
automatically set to the scrollport size to by the scrollport anymore.
Otherwise this would regress vertical writing-modes.
Differential Revision: https://phabricator.services.mozilla.com/D109512
No behavior change, just compute the different things we need upfront.
At first I was going to use this in the following patch but it ended up
not being needed.
Differential Revision: https://phabricator.services.mozilla.com/D109545
This is needed for bug 1700379, because otherwise we create a reference
frame with the root's scrolled content (the
::-moz-scrolled-page-sequence), and that breaks some display list
invariants.
Always create a canvas frame instead, (doesn't matter when printing
since we print off the page sequence frame directly), and create a
single ::-moz-page-sequence box.
Differential Revision: https://phabricator.services.mozilla.com/D109512
No behavior change, just compute the different things we need upfront.
At first I was going to use this in the following patch but it ended up
not being needed.
Differential Revision: https://phabricator.services.mozilla.com/D109545
Remove a bit of the aStyleDisplay gunk that shouldn't be needed because
of two reasons:
* Stylo is faster / has the style display one pointer-chase away, as
opposed to the old style system.
* We now check the MAY_BE_TRANSFORMED bit first now, and we deal with
SVG-transformed frames, so for non-transformed frames IsTransformed
should just be a bit-check now.
Differential Revision: https://phabricator.services.mozilla.com/D109511
This is a real issue, but realistically we're probably not going to dig
a lot into it, and it wasn't really caused by the regressing bug in any
meaningful way.
Differential Revision: https://phabricator.services.mozilla.com/D109532
Chrome and Safari move selection at middle button down and does not modify the
range at middle button up. However, they handle middle button down with
`Shift` key is "continue selection". So, we should handle selection in
nsIFrame when `mousedown` event for middle mouse button is fired, but ignore
multiple selection, drag and drop and maintaining selection for aligning the
behavior to the other browsers.
This patch splits `nsIFrame::HandlePress()` and calls new method which
moves selection from `nsIFrame::HandleEvent()` when middle button is pressed.
(Note that this patch does not check whether middle click paste is enabled
because Chrome moves selection even on Windows which Chrome always disable
middle click paste on.)
With this change, "paste" event target is changed. Previously, we used target
of the preceding `mouseup` event, but we start to use the target of the
preceding `mousedown` event.
Note that even with this patch, we still behave differently from Chrome even
in the following cases:
- middle mouse button down in selected range, we collapse it, but Chrome keeps
the selection.
- middle mouse button click in selected range, we dispatch "paste" event, but
Chrome collapse selection and not dispatch "paste" event.
- middle mouse button down in selected range and up in different element,
Chrome does not modify the range nor dispatch "paste" event.
- Shift + middle mouse button in editable `<table>` works as non-editable
in Chrome, but our editor handles it with special path. Therefore, we
don't modify the range but dispatch "paste" event in the selected range.
Changing them requires bigger change and probably requires some other features'
behavior changes. Therefore, we shouldn't touch these issues until they are
actually reported as web-compat issues.
Differential Revision: https://phabricator.services.mozilla.com/D103997
Implement an observer to wait for correct window events in order to restore tab
content. Non-SHIP code restores about:reader scroll position after receiving
"AboutReaderContentReady" event, so to achieve the same thing with session
history in parent enabled, we can wait for "AboutReader:Ready" event.
Differential Revision: https://phabricator.services.mozilla.com/D108712
This is macOS only and behind the prefs widget.macos.native-context-menus and
browser.proton.contextmenus.enabled .
The big design question here is: Where do we put the fork in the road? How much
should the existing non-native popup management machinery know about the state
of the native menu? Which parts of the non-native state should a) reflect the
true native state, b) enter a special "handled natively" state, or c) lie?
This patch picks the following approach:
- The nsMenuPopupFrame of the root menupopup knows about the native menu; it
keeps it alive in its new mNativeMenu field.
- If the context menu has submenus, i.e. nested <menupopup> elements, the
nsMenuPopupFrames for those nested menupopups do not know anything about the
native menu.
- The mPopupState of natively-handled nsMenuPopupFrames is ePopupClosed.
- XULPopupElement::GetState, which queries the frame's mPopupState, also
returns "closed". This might cause problems in the future.
- The XUL popup manager's mPopups "menu chain" does not know about any open
native menus.
- The rollup widget also does not know about the native popup.
I've chosen to use ePopupClosed for native menus for the following reasons:
1. While mirroring / updating the state for the root menu would be doable
without too much trouble, it would be much more annoying to do the same for
nested menupopups of submenus. So if submenus will be ePopupClosed, it's
consistent for the root menu to also be ePopupClosed.
2. nsXULPopupManager has assertions (for example in MayShowPopup) that make
sure that the menu popup frame's mPopupState is consistent with the XUL
popup manager's mPopups menu chain. Keeping the two both "closed" is the
easiest way to achieve consistency.
Unless there are grave concerns with this approach, I suggest we go with it for
now and see what trouble arises.
Differential Revision: https://phabricator.services.mozilla.com/D109183
While nsInlineFrame and nsFirstLetterFrame are going to continue sharing the same code, nsRubyFrame will use the refactored version to compute its intrinsic sizes.
This way we can also eliminate the need for checking the intrinsic type inside the function.
This patch shouldn't change behavior. It's just a refactoring of existing code.
Differential Revision: https://phabricator.services.mozilla.com/D109227
Actually the page in this case starts getting styled _after_ the load
event, sometimes, but when that happens that also causes a white flash
in other browsers.
Differential Revision: https://phabricator.services.mozilla.com/D109392
Chrome and Safari either disable this or handle it badly. We don't handle it great so disable it.
Although the document principal looks like it can change I think if that happened at minimum the presshell would be recreated, which creates the ZoomConstraintsClient so we shouldn't need to register to be notified if this changes.
The other option would be to implement support for prevent default of double taps and then have modify pdf.js (if it doesn't already prevent default ctrl wheel events).
Differential Revision: https://phabricator.services.mozilla.com/D109421
When a contentful paint occurs which doesn't come from Tick, we should
not generate a first-contentful-paint entry for it because
1) It violates the spec
2) It usually means some magical paints which we should not expose
to the web.
So this patches stop generating a contentful paint entry for that,
instead asking the next tick to generate the entry.
Depends on D107858
Differential Revision: https://phabricator.services.mozilla.com/D107859
This parsing is hidden behind the pref layout.css.page-size.enabled.
It isn't ideal that we parse this as a property, but we can't treat it as a
descriptor because of compatibility issues with other browsers. There are also
outstanding spec issues related to how descriptors like page-size are cascaded,
and whether the !important specifier is valid or not.
Differential Revision: https://phabricator.services.mozilla.com/D103958
To know the valid rules for each property, we need to put this information
into the Servo prop list and add an appropriate getter to Longhand/Shorthand.
Differential Revision: https://phabricator.services.mozilla.com/D105825
This patch incorporates flex item's margin and flex container's padding
when computing flex container's overflow area in both the inline axis
and block axis.
overflow-top-left.html starts to fail because the test has flex items
with margin contributing to the overflow area now. We leave the test
unchanged for now until the webcompat situation is clear (Bug1698428).
flexbox-overflow-padding-002.html is based on
flexbox-overflow-padding-001.html with `writing-mode: vertical-rl` and
`direction: rtl` added to `.flexContainer`.
Differential Revision: https://phabricator.services.mozilla.com/D107936
In ScrollFrameHelper::BuildDisplayList(), before comparing the clipRect
with scrollable overflow area, we should deflate the clipRect with
padding if overflow-clip-box is content-box in any axis, to get the
correct content-box dimension in that axis.
overflow-clip-box-3.html is adapted from the testcase attached in
bug 1226305 comment 0.
Differential Revision: https://phabricator.services.mozilla.com/D109097
Delete <script> and reftest-wait because the scrollbar shouldn't be
fading in the reftest, and we can save 5 seconds on CI!
Use default monospace font which is good enough without fuzziness.
Delete style for textarea because there is no textarea in the test nor
in the reference.
Differential Revision: https://phabricator.services.mozilla.com/D109193
Simon Giesecke
Csoregi Natalia
Jonathan Kew
Emilio Cobos Álvarez
Butkovits Atila
Timothy Nikkel
Masayuki Nakano
Miko Mynttinen
Anny Gakhokidze
Markus Stange
Noemi Erli
Xidorn Quan
smolnar
Kagami Sascha Rosylight
Sean Feng
Emily McDonough
Ting-Yu Lin
Cosmin Sabou
Andrew Halberstadt