Rename so that its naming is consistent with ReflowConfig::mColISize,
and to avoid confusion with ColumnBalanceData::mMaxBSize.
Differential Revision: https://phabricator.services.mozilla.com/D88697
For android SurfaceTexture and AndroidHardwareBuffer, GPU/hardware task end could be checked by android fence. Then their TextureHost do not need to be held by AsyncImagePipelineManager::mTexturesInUseByGPU.
Differential Revision: https://phabricator.services.mozilla.com/D88239
We can only assert that the array length is writable for the
`handleTrue = true` case. This also requires to reintroduce the writable array
length check to the Ion IC code.
Added tests to cover multiple scenarios where the StoreDenseElementHole IC is
used.
Differential Revision: https://phabricator.services.mozilla.com/D88031
There are cases where the code rebuilds the ScrollMetadata for a scrollframe
multiple times. This violates implicit assumptions in the NotifyApzTransaction
code that it will only be called after the ScrollMetadata is built for a particular
transaction. This patch moves the NotifyApzTransaction call to the end of the
metadata-building phase so that those assumptions are upheld.
Differential Revision: https://phabricator.services.mozilla.com/D88650
There are three cases,
- Move to inner OOP frame.
- Move to outer OOP frame.
- Move to an OOP frame that is in different sub-tree.
We could use common BrowserParent ancestor to determine which case is and
dispatch MouseExitFromWidget event with proper ExitFrom type.
Depends on D84748
Differential Revision: https://phabricator.services.mozilla.com/D84761
eTopLevel is reused in content process to indicates that the mouse leaves
the puppet widget rendering area, now we add a separated type, ePuppet, for it.
Differential Revision: https://phabricator.services.mozilla.com/D84748
Solving this is as simple as adding "click" to the list of events allowed to start an engagement event. Previously, we didn't have any clicks that could start an engagement event (although we allowed `mousedown` for focusing the Urlbar). Now, we have a few click events that start something that could be considered engagement: clicking a one off and clicking the exit button on the search mode indicator.
When engagementEvent.start() is called, [we bail](https://searchfox.org/mozilla-central/rev/ce21a13035623c1d349980057d09000e70669802/browser/components/urlbar/UrlbarController.jsm#720) if we're currently in an engagement. I can no longer trigger the error in the bug in regular Firefox use; I assume at the time this bug was filed, it was possible to record/discard an engagement by clicking the one-offs a second time. The second click would call `engagementEvent.start()` again and the error would be throw since we discarded the previous engagement event. This no longer seems to be the case. I can trigger it from tests though. That's because this is a common pattern in our tests:
```
await UrlbarTestUtils.promiseAutocompleteResultPopup({
window,
value: TEST_QUERY,
});
await UrlbarTestUtils.enterSearchMode(window);
```
If we don't include `fireInputEvent: true` in our call to `promiseAutocompleteResultPopup`, the view is opened without ever starting an engagement event. Then when `enterSearchMode` clicks a one-off, we call `UrlbarInput.startQuery`, which starts an engagement event. The error follows.
Adding click to the list of allowedEvents fixes this in tests and addresses any edge cases we might create in the future where the user is able to click a one-off without already being in an engagement event.
Depends on D87510
Differential Revision: https://phabricator.services.mozilla.com/D88480
For now, we *only* use this new page-skipping code during print preview, via a
PresContext::IsScreen() check. There's a separate legacy codepath that we'll
continue to use for skipping pages during actual printing; see e.g.
nsPageSequenceFrame::DetermineWhetherToPrintPage(). I intend to replace that
codepath soon, but for now I'm leaving it intact, in the interests of making
this patch minimally invasive & low-risk for beta uplift.
Differential Revision: https://phabricator.services.mozilla.com/D87394
Print settings stores margin units in TWIPS, but the API expects inches.
This was causing an extra conversion from inches to TWIPS on values that
were already in TWIPS.
Differential Revision: https://phabricator.services.mozilla.com/D88674
This patch shouldn't change behavior at all.
Since our print reflow pipeline doesn't try to handle incremental reflow (per
the early return in nsPageSequenceFrame::Reflow), we can safely assume that our
page frames don't have a preexisting next-in-flow (until we explicitly create
one for them).
This simplifies the logic & the number of scenarios that we need to consider.
Differential Revision: https://phabricator.services.mozilla.com/D88470
This patch shouldn't change behavior.
After this change, we'll be able to reason about the page range during reflow
(in a later patch in this series). The old place where we determine the
page-range information -- in nsPageSequenceFrame::StartPrint -- unfortunately
runs *after* reflow. So that was running too late for the information to be
useful when we're laying out pages on sheets.
Differential Revision: https://phabricator.services.mozilla.com/D88469
This patch shouldn't change behavior at all; it's just moving some member
variables to a new home on a helper-struct (and the struct's lifetime is the
same as the lifetime of the nsPageSequenceFrame where these member variables
lived, prior to this patch).
These members need to move so that PrintedSheetFrame can have access to them.
PrintedSheetFrame is now where pages are generated, and it will handle our
page-range-induced page skipping, as of a later patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D88468
Our data indicates a few users of x86 system hit failure to load urlmon.dll
for unknown reasons. Since we don't always require urlmon.dll,
we delay-load it, which causes a crash if loading urlmon.dll fails.
A proposed fix is to dynamically load urlmon.dll on x86.
Differential Revision: https://phabricator.services.mozilla.com/D88534
