This doesn't change behavior just yet, but seems worth doing separately.
With this patch, we can render content overlaid on top of an image
frame, by attaching a shadow root to it. The idea is to use this for
text recognition (OCR) of text inside images.
I chose to implement this using the DynamicLeaf stuff that I removed in
bug 1746310 (because nsMenuPopupFrame was its only user).
That seems simpler than either a new frame class, or more special cases
in the frame constructor, etc. But let me know if you disagree.
There are further changes that we want to do. For example, trying to
select the overlaid text with the mouse right now will start dragging
the image. For that, we might need to tweak our selection / mouse
dragging code. But those seem all changes that can go on top of this.
Differential Revision: https://phabricator.services.mozilla.com/D140638
This patch was originally posted to bug 1756762, however we found a better patch to fix that bug. This patch still seems like a good idea though so we want to land it in another bug.
I observed the following sequence of events when running gfx/layers/apz/test/mochitest/browser_test_background_tab_load_scroll.js in one of the cases that it fails for me locally.
-ScrollFrameHelper::NotifyApzTransaction is called after sending a transaction to webrender, this sets mAllowScrollOriginDowngrade = true.
-the scroll frame is destroyed and re-created (I'm not sure why this destroy and re-create happened, I didn't investigate), we call SaveState and RestoreState. So now mLastScrollOrigin == Other, and mAllowScrollOriginDowngrade == true.
-the test calls ScrollBy, so we get a call to ScrollToImpl with aOrigin == Relative
-aOrigin gets changed to Other here https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/generic/nsGfxScrollFrame.cpp#2979
-the code just below that determines that it is not a downgrade, so we update mLastScrollOrigin to Other (not a change) and set mAllowScrollOriginDowngrade = false
-ScrollFrameHelper::NotifyApzTransaction is _not_ called (probably because we are in a background tab), so mAllowScrollOriginDowngrade remains false
-the scroll frame is now at position 20000 and the visual viewport offset (stored on the presshell) is also 20000.
-the scroll frame is destroyed and re-created (this one I investigated, it's because the font subsystem has finished loading and asks for a global reconstruct https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/base/PresShell.cpp#9830), we call SaveState and RestoreState. So mLastScrollOrigin == Other, and mAllowScrollOriginDowngrade == true (the same values.
-we get a call to ScrollToRestoredPosition for the newly re-created scroll frame, we are trying to scroll from the current layout scroll position of 0 to the one we had before destruction and re-creation (20000). The visual viewport offset that is stored on the presshell has not been affected, it is still 20000.
-this gets to ScrollToImpl and with aOrigin == Restore
-we arrive at https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/generic/nsGfxScrollFrame.cpp#3000 and Restore is a downgrade from Other, and mAllowScrollOriginDowngrade is false so we do not change mLastScrollOrigin (still Other) and mAllowScrollOriginDowngrade remains false
-we arrive at the code in ScrollToImpl that updates the visual viewport offset on the presshell https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/generic/nsGfxScrollFrame.cpp#3232
-mLastScrollOrigin is Other, which can clobber apz, so we enter the if and add the difference between the before/after layout scroll position from this ScrollToImpl call (20000-0 = 20000) to the visual viewport offset (20000), getting 40000, which gets clamped to the max ~38000.
-and now the layout scroll position and the visual viewport offset have been detached when they shouldn't be.
Whenever we are doing a Restore scroll we expect that there has been a ScrollToImpl call in the past that got us to the position we are restoring to, and that past ScrollToImpl call should have resulted in the visual viewport offset on the presshell getting updated. So if the origin is Restore then the visual viewport offset should have already incorporated this scroll, and so we don't need to update the visual viewport offset for this scroll. If our assumption that the visual viewport offset on the presshell is already up-to-date is wrong that is okay because after an apz transaction they will be reconciled: the main thread is only trying to make an effort to sync with apz in advance and it is better to be conservative here, only updating the visual viewport offset when we know its correct, because as we've seen if we incorrectly update it they can get out of sync and cause bugs.
Another way to think of it: mLastScrollOrigin is the accumulation of all scroll origins since sending the last apz transaction and tells apz if the main thread should take precedence over the apz scroll position, and similarly the layout scroll position that we sned to apz is the accumulation of all scrolls since the last apz transaction. Whereas aOrigin tells us about one scroll, and we want to treat each scroll in that accumulation separately for determining how to update the main thread copy of the visual viewport offset.
Previously in https://phabricator.services.mozilla.com/D137873 I had stated that bug 1753881 (have PresShell::GetVisualViewportOffset() either return a maybe or layout scroll offset if vv offset is not set) would fix these cases in the test but I didn't understand why. Now I understand why. The reason is that although there is an obvious patch for bug 1753881 (return the layout scroll offset if the visual viewport offset isn't set) that patch is not correct. The reason is that in PresShell::SetVisualViewportOffset https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/base/PresShell.cpp#11199 we compare the new offset to the old offset which we get by calling GetVisualViewportOffset. So in the common case where we are in ScrollToImpl and we update the layout scroll offset and then call SetVisualViewportOffset to update the visual viewport offset then GetVisualViewportOffset is going to return the already updated layout scroll offset (if the visual viewport offset hasn't been set on the presshell yet). So SetVisualViewportOffset will determine that we are already up to date and not end up setting any visual viewport offset on the presshell at all. And so no visual viewport offset gets set at all. And since the original bug comes about because of a disagreement between the visual viewport offset and the layout scroll offset, we avoid the bug entirely by never setting a visual viewport offset. This is not acceptable because we thus never send visual viewport offset change events (mozvisualscroll) which we have several tests depending on (browser/components/sessionstore/test/browser_scrollPositions.js is one in particular that I want to note).
The reason I wanted to note browser/components/sessionstore/test/browser_scrollPositions.js was that this patch causes that test to fail. What happens in the test is a scroll frame gets a non-zero layout scroll position (and the same visual viewport offset on the presshell), then the page is reloaded. The layout scroll position is restored via a call to ScrollToImpl with origin Restore, thus it does not touch the visual viewport offset on the presshell. Before this patch we would have looked at mLastScrollOrigin instead and touched the visual viewport offset. And because the page was reloaded we got a new presshell so it does not have a visual viewport offset. The test then gets the visual viewport offset and expects it to have the non-zero layout scroll offset, but it does not. So we can fix this by landing the (corrected) patch for bug 1753881 (have PresShell::GetVisualViewportOffset() either return a maybe or layout scroll offset if vv offset is not set).
Differential Revision: https://phabricator.services.mozilla.com/D139473
WebRenderBridgeChild::GetFontKeyForScaledFont can currently cause a IpcResourceUpdateQueue race.
If we're in the middle of a transaction building a blob image, GetFontKeyForScaledFont is called
in the blob image building code using the transaction's IpcResourceUpdateQueue as expected, such
that resource updates are sent out when the transaction is finalized.
However, TextDrawTarget calls into PushGlyphs without passing along its IpcResourceUpdateQueue,
calling GetFontKeyForScaledFont without it, and causing it to immediately send out the resource
update.
So if a blob image uses a font key and submits a resource update, but a display list is built
after that also using the font key within the transaction, the display list will fail to send
the resource update because it thinks the blob image already did, even though the blob image
transaction has not yet been finalized.
The simple fix is to just pass IpcResourceUpdateQueue from TextDrawTarget into PushGlyphs, thus
ensuring the resource updates are properly ordered.
Differential Revision: https://phabricator.services.mozilla.com/D140438
None of these changes should change the behavior.
- In `ConsiderChildOverflow()`, replace the legacy term "visual" overflow.
- `GetOverflowAreasRelativeToSelf()`, `ScrollableOverflowRectRelativeToSelf()`,
`InkOverflowRectRelativeToSelf()` can really be terser.
- Replace `mRect.TopLeft()` with `Position()`, and
`nsRect(nsPoint(0, 0), GetSize())` with `GetRectRelativeToSelf()`, making them
shorter and clearer.
- Move `GetOverflowRect()` to private section because it's an implementation
detail of `InkOverflowRect()` and `ScrollableOverflowRect()`.
Differential Revision: https://phabricator.services.mozilla.com/D140437
When a position:sticky element "sticks" in the scroll container's scrollport, we
compute its containing block's overflow areas by including its overflow areas
located at its relative position. This makes the element's normal position
unreachable because its overflow areas located at its "normal position" might
not be within its containing block's overflow areas. Block frame doesn't have
this problem because `nsLineBox` always includes the element's normal position
rect in its own rect.
Therefore, when including a sticky child frame's overflow area into its parent's
overflow area, the overflow areas located at its normal position should be
included as well. This behavior is consistent with a relatively positioned child
frame. (A position:relative frame's normal position is always reachable when
scrolling, at least in both axes that grow positively.)
Differential Revision: https://phabricator.services.mozilla.com/D140373
Automatically generated rewrites of all ParamTraits and IPDLParamTraits
implementations in-tree to use IPC::Message{Reader,Writer}.
Differential Revision: https://phabricator.services.mozilla.com/D140004
`nsIFrame::IsRelativelyPositioned()` tests "position:relative" or
"position:sticky", but its naming is misleading until you've dug into the
underlying helper `nsStyleDisplay::IsRelativelyPositionedStyle()`.
Differential Revision: https://phabricator.services.mozilla.com/D140273
This gets done usually in BreakSink::Finish, but we don't do
line-breaking in SVG Text so we need to do this here instead.
Do you know where I could crib a test for this?
Depends on D139964
Differential Revision: https://phabricator.services.mozilla.com/D139965
The regular scroll position restoration code will restore it.
Specifically, in ScrollFrameHelper::SaveState
https://searchfox.org/mozilla-central/rev/44ae61c5eeb150cb77b6b8511ceee7ddd6892cb7/layout/generic/nsGfxScrollFrame.cpp#7376
we store the visual viewport offset. ScrollFrameHelper::ScrollToRestoredPosition will try to restore both the layout scroll offset and the visual viewport offset by calling ScrollToWithOrigin (which leads to ScrollToImpl) and PresShell::ScrollToVisual respectively.
I observed the following sequence of events when running gfx/layers/apz/test/mochitest/browser_test_background_tab_load_scroll.js in one of the cases that it fails for me locally.
-ScrollFrameHelper::NotifyApzTransaction is called after sending a transaction to webrender, this sets mAllowScrollOriginDowngrade = true.
-the scroll frame is destroyed and re-created (I'm not sure why this destroy and re-create happened, I didn't investigate), we call SaveState and RestoreState. So now mLastScrollOrigin == Other, and mAllowScrollOriginDowngrade == true.
-the test calls ScrollBy, so we get a call to ScrollToImpl with aOrigin == Relative
-aOrigin gets changed to Other here https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/generic/nsGfxScrollFrame.cpp#2979
-the code just below that determines that it is not a downgrade, so we update mLastScrollOrigin to Other (not a change) and set mAllowScrollOriginDowngrade = false
-ScrollFrameHelper::NotifyApzTransaction is _not_ called (probably because we are in a background tab), so mAllowScrollOriginDowngrade remains false
-the scroll frame is now at position 20000 and the visual viewport offset (stored on the presshell) is also 20000.
-the scroll frame is destroyed and re-created (this one I investigated, it's because the font subsystem has finished loading and asks for a global reconstruct https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/base/PresShell.cpp#9830), we call SaveState and RestoreState. So mLastScrollOrigin == Other, and mAllowScrollOriginDowngrade == true (the same values.
-we get a call to ScrollToRestoredPosition for the newly re-created scroll frame, we are trying to scroll from the current layout scroll position of 0 to the one we had before destruction and re-creation (20000). The visual viewport offset that is stored on the presshell has not been affected, it is still 20000.
-this gets to ScrollToImpl and with aOrigin == Restore
-we arrive at https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/generic/nsGfxScrollFrame.cpp#3000 and Restore is a downgrade from Other, and mAllowScrollOriginDowngrade is false so we do not change mLastScrollOrigin (still Other) and mAllowScrollOriginDowngrade remains false
-we arrive at the code in ScrollToImpl that updates the visual viewport offset on the presshell https://searchfox.org/mozilla-central/rev/9b0bdcc37419e6765223358a31a4a54d62e1cd97/layout/generic/nsGfxScrollFrame.cpp#3232
-mLastScrollOrigin is Other, which can clobber apz, so we enter the if and add the difference between the before/after layout scroll position from this ScrollToImpl call (20000-0 = 20000) to the visual viewport offset (20000), getting 40000, which gets clamped to the max ~38000.
-and now the layout scroll position and the visual viewport offset have been detached when they shouldn't be.
If we reset the visual viewport offset when the scroll frame is destroyed we avoid the problem here.
Differential Revision: https://phabricator.services.mozilla.com/D139792
This patch is generated via:
```
rg -l 'BlockReflowInput' layout/ | xargs sed -i 's/BlockReflowInput/BlockReflowState/g'
```
Manual fixes are in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D139439
Its type is not `BlockReflowInput` but an ordinary `ReflowInput`. Rename it to
`mLineContainerRI` to match its accessor.
While I'm here, I change `mLineContainerRI` to be a reference since it cannot be
nullptr (see nsLineLayout's constructor); also, replace
`mLineContainerRI->mFrame` with `LineContainerFrame()`.
Differential Revision: https://phabricator.services.mozilla.com/D139438
We need them for SVG primitives.
This patch adds a bit of plumbing to disable snapping some of the primitives and forcing the antialiasing shader feature where needed, and uses it for SVG solid rectangles and images.
Differential Revision: https://phabricator.services.mozilla.com/D139024
Bug 1682686 added the tests which need
layout.css.grid-item-baxis-measurement.enabled to be set to `true` independent
of the release channel.
Differential Revision: https://phabricator.services.mozilla.com/D139410
The code at the end of ComputeFinalBSize() does not handle
"box-decoration-break:clone" and the cases where the block frame's reflow status
can change from incomplete to complete. This patch is an attempt to fix all the
possible scenarios.
Differential Revision: https://phabricator.services.mozilla.com/D138967
ComputeFinalBSize() gets most of its input parameters from BlockReflowInput's
members. Passing BlockReflowInput into it directly so that it can access more
precomputed data in BlockReflowInput such as `ContentBEnd()`.
This is a preparation for the next part that is going to rewrite a large portion
of ComputeFinalBSize().
Differential Revision: https://phabricator.services.mozilla.com/D138966
This patch removes more main thread dependencies from the content side
of WebGPU. Instead of issuing a resource update for an external image,
we now use an async image pipeline in conjunction with
CompositableInProcessManager from part 1. This allows us to update the
HTMLCanvasElement bound to the WebGPU device without having to go
through the main thread, or even the content process after the swap
chain update / readback has been requested.
Differential Revision: https://phabricator.services.mozilla.com/D138887
This patch removes more main thread dependencies from the content side
of WebGPU. Instead of issuing a resource update for an external image,
we now use an async image pipeline in conjunction with
CompositableInProcessManager from part 1. This allows us to update the
HTMLCanvasElement bound to the WebGPU device without having to go
through the main thread, or even the content process after the swap
chain update / readback has been requested.
Differential Revision: https://phabricator.services.mozilla.com/D138887
We already call MaybeQueueCacheUpdateForStyleChanges from DidSetComputedStyle for reconstructed frames.
However, at that point, nsIContent::GetPrimaryFrame (and thus LocalAccessible::GetFrame) returns null, which means we're unable to check for style changes.
Instead, we now handle style changes for reconstructed frames in PruneOrInsertSubtree, at which point the frame is definitely available.
Differential Revision: https://phabricator.services.mozilla.com/D138627
If a block container has box-decoration-break:clone, its block-end border and
padding (BP) are *usually* drawn at the block-end edge of the current
column/page. Thus, when computing the available block-size for its children, we
should subtract its block-end border BP from it.
When I claim the block-end BP are *usually* drawn at the block-end edge of the
column/page, the exception is when a block container with a definite block-size
runs out of its block-size in a column/page. In this case, the block-end BP is
drawn at the block-end edge of its content-box. This patch wires the effective
content-box block-size computed in nsBlockFrame::Reflow() into
BlockReflowInput's constructor, and we do not subtract its block-end border BP
from the `mContentArea.BSize(wm)` when this case happens.
`BlockReflowInput::ContentBSize()` is the correct available block-size to reflow
the children, precomputed in BlockReflowInput's constructor. See
https://searchfox.org/mozilla-central/rev/c12a59323ee46b29b90c9917a3a7a70ea714ffec/layout/generic/BlockReflowInput.cpp#118-126
The remove hunk was a hack, working only for ColumnSetWrapper with
`box-decoration-break:clone`. It's no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D138367
If the visual viewport offset is not set on the presshell then calling GetVisualViewportOffset returns (0, 0). This then causes us to introduce an incorrect offset between the layout scroll offset and the visual viewport offset that didn't exist before.
Logically we want to treat an unset visual viewport offset as the layout scroll offset.
Other possible fixes:
-make PresShell::GetVisualViewportOffset return the layout scroll offset if a visual viewport offset is not set
-make this if conditional on a visual viewport offset already being set
-the combination of the two above
All of these fail some tests on try server. I haven't investigated why. If we want to go with any of those potential fixes in the future then this patch is a step on the way there
Differential Revision: https://phabricator.services.mozilla.com/D137873
This patch ensures that we only update the external image resource for
WebGPU when there has been an actual change for the resource. In order
to guarantee this, we wait for the present to complete, and only then
issue the update. WebRenderBridgeChild::SendResourceUpdates will also
trigger a frame generation if any resources were changed, which means we
don't need to trigger a paint on the frame itself anymore.
Note that we still have a race condition when we write into the
MemoryTextureHost while in PresentCallback, and the renderer thread may
be accessing the pixel data to upload to the GPU.
Differential Revision: https://phabricator.services.mozilla.com/D138349
ScrollFrameHelper::GetVisualViewportOffset will return a pending vv offset if there is one. So if there is a pending vv offset this line will instantly turn it into the current vv offset. This is not how the pending vv offset is supposed to work. It should get sent over to apz, apz can then decide to accept or reject it based on whether it knows about user scrolling that overrides it.
I saw this while reading code for something else, so I don't know of anything specific this fixes.
Depends on D137720
Differential Revision: https://phabricator.services.mozilla.com/D137721
Currently, we pass all the five fields in FlexLayoutResult separately into
ReflowChildren(), but we really should just pass FlexLayoutResult instead.
Differential Revision: https://phabricator.services.mozilla.com/D138100
We've got the tentative cross size before calling DoFlexLayout() in Reflow(), so
we can just use that value in DoFlexLayout and a few other methods.
Also, add "ContentBox" to naming of the main size argument ComputeMainSize().
Differential Revision: https://phabricator.services.mozilla.com/D137365
I found in/out parameters confusing when reasoning the data flow. Aggregating
DoFlexLayout's output data in a struct also reduces DoFlexLayout's number of
arguments.
Differential Revision: https://phabricator.services.mozilla.com/D137364
The `struts` array is used only within DoFlexLayout, so we should move it into
`if (!GetPrevInFlow()) { ... }` branch.
Also, move `nsTArray<StrutInfo>&` argument on DoFlexLayout() to the second to
last place so that the output arguments are grouped together after applying Part
4.
Differential Revision: https://phabricator.services.mozilla.com/D137363
Move the assertion for unconstrained isize to the beginning of Reflow() because
we check it in all cases -- in GetMainSizeFromReflowInput when a flex container
is row-oriented, or in the old code computing gap size and ComputeCrossSize()
when a flex container is column-oriented.
Differential Revision: https://phabricator.services.mozilla.com/D137361
This adds a round trip from double -> float -> double because
CSSRect is float but it should be ok because most users of gfxRect (RectDouble)
should be using Rect instead anyways.
Differential Revision: https://phabricator.services.mozilla.com/D137811
There's no need to create a visual viewport offset here, only if one already exists do we want to clamp it.
I noticed this while reading code for something else, so I'm not sure if it actually fixes anything.
Differential Revision: https://phabricator.services.mozilla.com/D137720
This scaling factor is to account for ComputePagesPerSheetAndPageSizeTransform,
but that is not used when printing headers/footers, which resulted in the
reversed scale clipping the header/footer.
Differential Revision: https://phabricator.services.mozilla.com/D136830
We weren't doing it. I want to see if it helps with some flickering
intermittents with the patch of bug 1718220.
Not sure how to reliably test this.
Differential Revision: https://phabricator.services.mozilla.com/D137794
This scaling factor is to account for ComputePagesPerSheetAndPageSizeTransform,
but that is not used when printing headers/footers, which resulted in the
reversed scale clipping the header/footer.
Differential Revision: https://phabricator.services.mozilla.com/D136830
The reason why the global ScrollGeneration::sCounter doesn't work for the APZ
case is the APZ sampler thread is per our top level browser window, so if
there are multiple browser windows at the same time, the sCounter will be muted
from different sampler threads.
Differential Revision: https://phabricator.services.mozilla.com/D133439
This was added in bug 1201330 but with WR isn't really needed anymore and the code causes the expiration timer to fire until the scroll frame becomes inactive (the most common scroll frames stay active, ie root scroll frames).
Differential Revision: https://phabricator.services.mozilla.com/D136806
In general, we don't need to store used border and padding in a derived frame
class, nsIFrame::GetLogicalUsedBorderAndPadding() already provides the data.
While auditing the consumer of `mBorderPadding`, I realize that
nsHTMLCanvasFrame's fragmentation never works because
nsCSSFrameConstructor::CreateContinuingFrame() never creates its continuation,
and nsHTMLCanvasFrame::Reflow() never returns an incomplete reflow status to its
parent.
This patch removes the code that pretended to handle fragmentation to avoid any
confusion. Luckily, with `layout.display-list.improve-fragmentation` enabled by
default, we can still print <canvas> without data loss.
Differential Revision: https://phabricator.services.mozilla.com/D136649
The old code operates in the CSS pixel coordinate, so we should use the type
system to express that. With this patch, nsImageControlFrame, nsImageFrame, and
nsImageMap now have no usage of nsIntPoint.
Differential Revision: https://phabricator.services.mozilla.com/D136647
Depends on D136163
I have a feeling this isn't exactly the right way to pass this info, since the old WR code must have known about the perspective node without using my new flag.
Differential Revision: https://phabricator.services.mozilla.com/D136180
I added this check in bug 1725569 because I said it matched other browsers. I'm not sure what testing I did there, or I made a mistake or what but the behaviour is not consistent between browsers.
For top level documents on initial load Safari sends a resize event, Chrome does not. Firefox sends a resize event.
For iframes Chrome and Safari send a resize event. Firefox usually sends a resize event.
Given the inconsistent behaviour here it seems better to err on the side of sending resize events because sites depend on it and might not work without it.
In the testcase from the bug I am able to reproduce about 20% of the time, and the problem is the first reflow check. So I'm removing that and I think it will fix the problem the user is seeing (which sounds to be more consistent).
Differential Revision: https://phabricator.services.mozilla.com/D135698
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
nsPageSequenceFrame does a thing where it grows its desired size to fit the
AvailableISize and ComputedBSize (under the assumption that those are the
actual dimensions of our scrollport, which it wants to make maximal use of).
This behavior causes trouble when it's reflowed under the privileged
'sizeToContent' JS API. That API makes us reflow with nscoord_MAX as the
viewport's ComputedBSize(), and this nscoord_MAX value gets passed down to be
the nsPageSequenceFrame's ComputedBSize as well. When we reach the code in
question, we dutifully grow the desired size to that bogus huge value, which is
clearly wrong.
This patch addresses this issue by simply declining to grow the desired size in
the scenario where ComputedBSize() is unconstrained. This leaves us with
reasonable values for our desired size (which are actually based on the
content, which makes it the right thing to do for the purpose of a
SizeToContent() call).
Differential Revision: https://phabricator.services.mozilla.com/D135762
This patch fixed the following:
1. Make the helper support the vertical writing modes since its callers
GetMinISize() and GetPrefISize() are fully aware of the vertical writing modes.
`overflow-scroll-intrinsic-001.html` verifies this scenario. This also fixed a
testcase with "writing-mode: vertical-lr" in flexbox's
cross-axis-scrollbar.html.
2. Treat scrollbar's intrinsic size "zero" if we have "scrollbar-width: none"
since no scrollbar is showing at all.
`overflow-auto-scrollbar-gutter-intrinsic-003.html` verifies this scenario.
3. Return the scrollbar size if we have "scrollbar-gutter: stable", or twice the
size if we have "scrollbar-gutter: stable both-edges".
`overflow-auto-scrollbar-gutter-intrinsic-{001,002}.html` verifies this
scenario.
Differential Revision: https://phabricator.services.mozilla.com/D135182
Part of how invalidation works with WebRender is that we assume frames
with a WebRenderUserData object attached to them are in view. This means
for images that we must ensure we create an empty
WebRenderImageProviderData object even when we have no provider or
surface for display. This will allow us to invalidate properly when we
get the FRAME_COMPLETE notification from imagelib indicating that the
redecode has completed.
Differential Revision: https://phabricator.services.mozilla.com/D135077
This shouldn't change behavior but makes following the code a bit
easier. There's no point in using callbacks for touch-action as:
* We return the computed flags anyways.
* Each caller wants to do something different.
* (more importantly) The callback gets called synchronously.
So move the relevant code to TouchActionHelper and make the callers deal
with the flags as they please. I've preserved the behavior of only doing
the thing if the flags array is non-empty.
Differential Revision: https://phabricator.services.mozilla.com/D134933
The assertion here was added during the iterator refactoring in bug 1732349,
but is actually bogus. The old code would have returned via the MOZ_TRY_VAR
that wrapped the call to blockFrame->GetLineNumber(); that's replaced by
iter->FindLineContaining(), so we should now check for an error there and
similarly just return to the caller, not assert.
Differential Revision: https://phabricator.services.mozilla.com/D134950
We introduced this comment at the very beginning of the flexbox implementation.
Since then, WritingModes.h has obtained the utilities dealing with logical axis,
and CSSAlignUtils.h has supported CSS alignment for both flexbox and grid. All
the helper functions remaining in nsFlexContainerFrame.cpp are related to
flexbox, so I feel it's time we retire this comment.
NPOTB DONTBUILD because this patch changes only comments.
Differential Revision: https://phabricator.services.mozilla.com/D134652
In Flexbox spec 4.1, Example 3 [1]:
... since the absolutely-positioned box is considered to be
"fixed-size", a value of stretch is treated the same as flex-start.
Also, per Alignment 3 spec [2]:
The default fallback alignment for 'stretch' is 'flex-start'.
Thus, when computing the alignment for flexbox's abspos children in
CSSAlignmentForAbsPosChild(), we convert 'stretch' to 'flex-start', and let the
subsequent logic convert 'flex-start' to either 'start' or 'end', because
nsAbsoluteContainingBlock don't know how to deal with the flex-relative axis.
This patch makes us behave the same as Google Chrome on the modified testcases.
[1] https://drafts.csswg.org/css-flexbox/#abspos-items
[2] https://drafts.csswg.org/css-align/#valdef-align-content-stretch
Differential Revision: https://phabricator.services.mozilla.com/D134543
We now support scrollbar-gutter property. So for example, assume the scroll
container has "scrollbar-gutter:stable". When toggling the visibility of
inline-end scrollbar, we can skip the reflow for the scroll inner frame because
the available inline-size for it cannot change.
This patch teaches TryLayout() to consider the sizes of scrollbar gutter rather
than the (assumed) visibility of scrollbars when deciding the need to call
ReflowScrolledFrame().
Also, TryLayout() doesn't need to report an inconsistent layout unless
the (showHScrollbar, showVScrollbar) pair changes the sizes of scrollbar
gutters.
Differential Revision: https://phabricator.services.mozilla.com/D134373
Bug 1550869 made all the non-editable images return a `FrameTarget` with
`userFrameEdge=true`. When the user moves the mouse pointer to select an image
from its left edge, the mouse pointer needs to reach the right edge of the image
in order to complete the selection. This makes it difficult to select an image
at the end of a line.
This patch restores the behavior to select a non-draggable & non-editable image
to it was before bug 1550869. That is, we recognize the image selection when the
mouse pointer moves passed the middle point of the image
width (`OffsetsForSingleFrame`). Both blink and webkit have the same behavior,
but no spec text dictates this behavior, so I mark the wpt test as "tentative".
Differential Revision: https://phabricator.services.mozilla.com/D133960
Here are the ideas of the implementation.
1) When creating ScrollReflowInput, we compute and store the size of the
scrollbar-gutter in `mScrollbarGutterSizes.
2) Provide a ScrollReflowInput::ScrollbarGutter() API that returns the space
occupied by scrollbar gutters or scrollbars, and use it in ReflowScrolledFrame()
and TryLayout().
-----
For test changes:
- The existing scrollbar-gutter changes all assume classic scrollbars that can
create scrollbar gutters, so they won't pass on Android which uses overlay
scrollbars.
- Add scrollbar-gutter-002.html to test when the scrollbar and gutter
are both shown. The reference of this uses padding to simulate
scrollbar-gutter, so it's OK if the platform uses overlay scrollbars.
The next patch will add more variants.
- scrollbar-gutter-dynamic-001.html was never run. Fixed it by adding
`<link rel="match">`.
Differential Revision: https://phabricator.services.mozilla.com/D132664
Here are the ideas of the implementation.
1) When creating ScrollReflowInput, we compute and store the size of the
scrollbar-gutter in `mScrollbarGutterSizes.
2) Provide a ScrollReflowInput::ScrollbarGutter() API that returns the space
occupied by scrollbar gutters or scrollbars, and use it in ReflowScrolledFrame()
and TryLayout().
-----
For test changes:
- The existing scrollbar-gutter changes all assume classic scrollbars that can
create scrollbar gutters, so they won't pass on Android which uses overlay
scrollbars.
- Add scrollbar-gutter-002.html to test when the scrollbar and gutter
are both shown. The reference of this uses padding to simulate
scrollbar-gutter, so it's OK if the platform uses overlay scrollbars.
The next patch will add more variants.
- scrollbar-gutter-dynamic-001.html was never run. Fixed it by adding
`<link rel="match">`.
Differential Revision: https://phabricator.services.mozilla.com/D132664
Currently, mResizerBox's rect (variable `r`) partially depends on the result
of mScrollCornerBox's rect.
This patch makes mScrollCornerBox and mResizerBox compute their own rects (in
variable `r`) in separate if-statements because we can show resizer without
showing scroll corner (due to no scrollbar).
Differential Revision: https://phabricator.services.mozilla.com/D133694
HasResizer() is equivalent to mResizerBox and is used only within
ScrollFrameHelper, so no need to expose it. Also, remove some unreachable
if-branches.
Differential Revision: https://phabricator.services.mozilla.com/D133693
Revise vRect & hRect computation because the scrollbar gutter can be at both
inline start and inline end sides. For example, we can no longer use
`aInsideBorderArea.width - mScrollPort.width` to get the actual width of the
vertical scrollbar. We want to compute them in different ways.
Differential Revision: https://phabricator.services.mozilla.com/D133692
Compute the actual vertical & horizontal scrollbars' rects (vRect & hRect) only
when we decide to show the scrollbars. The rationale is that after introducing
scrollbar-gutter in bug 1715112, `mScrollPort` is no longer equal to
`aInsideBorderArea` even if we don't show scrollbars, and we want scrollbar
rects remaining empty to avoid showing them.
Simplify `hasVisualOnlyScrollbarsOnBothDirections` and move it closer to its
first usage.
Differential Revision: https://phabricator.services.mozilla.com/D133691
Currently, we use IsPhysicalLTR() to query which is the start side of the
physical left <-> right axis. However, for vertical row-oriented flex
containers, physical left <-> right axis is its cross axis. We really should
query IsBidiLTR() instead because its main axis is parallel to line-left <->
line-right axis (i.e. inline axis).
flexbox-justify-content-wmvert-003.html is adapted from
flexbox-justify-content-wmvert-002.html.
Differential Revision: https://phabricator.services.mozilla.com/D133168
This patch integrates OffscreenCanvasDisplayHelper with
HTMLCanvasElement, OffscreenCanvas and nsDisplayCanvas to allow
asynchronous display of an OffscreenCanvas.
Differential Revision: https://phabricator.services.mozilla.com/D130787
This patch integrates OffscreenCanvasDisplayHelper with
HTMLCanvasElement, OffscreenCanvas and nsDisplayCanvas to allow
asynchronous display of an OffscreenCanvas.
Differential Revision: https://phabricator.services.mozilla.com/D130787
For reducing the legacy behavior emulator of `nsContentUtils::ComparePoints`
and make it simpler, this patch makes it take `int64_t` as the offset.
Additionally, it's named "ComparePoints_AllowNegativeOffsets`.
Differential Revision: https://phabricator.services.mozilla.com/D132549
This patch fixes only the cases if the result of `ComputeIndexOf_Deprecated()`
is used as unsigned integer with implicit or explicit cast.
Differential Revision: https://phabricator.services.mozilla.com/D131336
It's hard to fix some callers. Therefore, in this bug, we should fix only
simple cases. Therefore, we should rename existing API first.
Differential Revision: https://phabricator.services.mozilla.com/D131334
They are defined as "unsigned long" by the standards. So we should use
`uint32_t` rather than `int32_t` with the methods. However, layout code
uses `int32_t` a lot for representing the offset. Therefore, this patch
adds `*_FixOffset1` etc for the cases which cannot fix easily in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D131110
It's an internal API corresponding to `Selection.getRangeAt` DOM API.
I think that it should use `uint32_t` rather than `size_t` because of the
consistency with the DOM API and `Selection::RangeCount()`.
This patch fixes all callers of `GetRangeAt()`, and rewrites it with ranged-
loops unless original ones do not refer `RangeCount()` every time and may run
script in the loop.
Differential Revision: https://phabricator.services.mozilla.com/D128848
Building with --disable-xul has been busted since _at least_ bug
1082579, for more than 7 years (I didn't try to track that down
further). It's time to recognize that the option serves no purpose.
Differential Revision: https://phabricator.services.mozilla.com/D133161
The basic part of the infrastructure of scroll-linked animations. This is
designed based on scroll-linked animation generated by CSS. We will
implement the timing computation and hook the ScrollTimeline to the CSS
animations in the following patches.
All the tests are in the patch that hooks ScrollTimeline to CSS Animation.
Differential Revision: https://phabricator.services.mozilla.com/D129100
This patch is inspired by `ScrollFrameHelper::GetActualScrollbarSizes()` that
uses a nsMargin to represent the space occupied by scrollbar.
In bug 1715112, TryLayout is going to consider the space occupied by the
scrollbar gutter. Hence the variable name with gutter in it just to avoid change
the variable name again.
Differential Revision: https://phabricator.services.mozilla.com/D132663
The static AddRemoveScrollbar() helper is meant to adjust the scroll port and
test whether the scrollbar fits, but its interface is obscure. By expanding the
helper in-place, the code should now become easy to follow, and we can also
remove the wordaround that sets the bool:1 bitfield.
Differential Revision: https://phabricator.services.mozilla.com/D132759
Previously with ImageContainers, we would put the new preferred surface
into the ImageContainer. When we check if we should invalidate, it would
have a different image key, and hence invalidate the image frame and
schedule a paint.
With ImageProviders, it returns the same key in this case, because the
ImageProvider represents a particular surface. As such, we need to
actually track when we get a substituted ImageProvider, and invalidate
the image frame more aggressively to ensure we get the preferred size.
Differential Revision: https://phabricator.services.mozilla.com/D132583
I considered removing this class initially, but it's actually a pretty
useful abstraction over the DateTimeFormat interface when used
specifically with Gecko. It applies the OS preferences and provides some
caching behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131671
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
Technically, `aContentArea` is not 100% wrong; its the content area of the outer
scroll frame, which contains the content area of the inner scrolled frame, the
padding, and the scrollbars. However, it should really be named
`aInsideBorderArea` as the caller names it. Otherwise, it is easy to cause
confusion with the content area of the inner scrolled frame.
Also, rename `aOldScrollArea` as well so that we use the term "scroll port"
consistently.
Differential Revision: https://phabricator.services.mozilla.com/D132445
Scrollbar's min and pref sizes won't change during reflow, so we can cache them
in ScrollReflowInput to save some repetitive computation in multiple
ReflowScrolledFrame() and TryLayout() calls.
This is also a preparation for Bug 1715112 because we can use the pref sizes to
compute the scrollbar-gutter size in ScrollReflowInput.
Differential Revision: https://phabricator.services.mozilla.com/D132443
It should be sufficient to call `SetScrollbarMediatorContent` once in
ScrollReflowInput's constructor, which is created in the beginning of
nsHTMLScrollFrame::Reflow(), instead of calling it repeatedly in multiple
TryLayout() calls.
Differential Revision: https://phabricator.services.mozilla.com/D132442
We've had some APIs passing ScrollReflowInput by reference while some others
using pointer. Let's unify them by using reference everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D132441
They shouldn't be scattered in nsHTMLScrollFrame::Reflow(). Also, reorder these
assignment operations according to the member variables' appearance order in
ScrollReflowInput.
I also moved the constructor out of the class definition because it becomes a
large method, and I'm going to add `private:` section after the methods section
in a later patch.
Differential Revision: https://phabricator.services.mozilla.com/D132440
I considered removing this class initially, but it's actually a pretty
useful abstraction over the DateTimeFormat interface when used
specifically with Gecko. It applies the OS preferences and provides some
caching behavior.
Differential Revision: https://phabricator.services.mozilla.com/D131671
Applying it to SVG-transformed frames is wrong, and causes us to
rasterize rather massive SVGs. This is consistent with the other CSS
3d transforms code, and our rendering of the test-case matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D132040
Given the compat reports in bug 1484928, I don't think it's worth
keeping the current behavior.
Our behavior should match other browsers now. Rather than making
content: url() work everywhere even for otherwise-replaced elements,
just special-case this since that's what other browsers seem to do.
Differential Revision: https://phabricator.services.mozilla.com/D131797
This causes (among other things) pages to be dark when using regular
windows system colors and forcing colors to "always", which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D131165
This patch potentially changes the behavior when the scrolled frame is in
vertical writing-mode, but it should be the correct way to handle the scrollbar
change.
Differential Revision: https://phabricator.services.mozilla.com/D130711
LineBreaker::Strictness is just an alias of LineBreakRule in Segmenter.h. This
is to reduce the dependency of the legacy LineBreaker.
Differential Revision: https://phabricator.services.mozilla.com/D131026
LineBreaker::WordBreak is just an alias of WordBreakRule in Segmenter.h. This is
to reduce the dependency of the legacy LineBreaker.
Differential Revision: https://phabricator.services.mozilla.com/D131025
test_abort_smooth_scroll_by_instant_scroll.html in this comment is a test case
to make sure this change doesn't regress a case where a smoothe scrolling run
by an APZC is replaced by an instant scroll operation by script.
Some other mochitests for this change are in the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D129594
In some platforms (like macOS, windows dark mode, android, and some gtk
themes) the foreground selection color might be `currentcolor`, and that
doesn't generally guarantee enough contrast with the attention
background.
Remove HeadlessLookAndFeelGTK's handling of this color since it's
useless (always overridden by prefs in all.js)
Differential Revision: https://phabricator.services.mozilla.com/D130617
Keep old behavior behind a pref.
I've kept the tests that failed enabling the pref because they're
somewhat hard to rewrite and I'd rather avoid that until we know this
will stick, specially since they test the guts of the recursive function
that I'm basically ~disabling.
I've checked that the rendering on those is sensible / matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D130717
The optimized code path for nested grid layout should only set the
BSize of the child frames, since this is what the optimization is
for.
Without the change, the ISize is always going to be set to 0 for
child frames which may break the layout. Sometimes, it is not
an issue because the ISize of the grid area gets updated, so
the cached measurement becomes invalid, and the ISize of the child
frame gets set to the correct one again.
Differential Revision: https://phabricator.services.mozilla.com/D130828
Keep old behavior behind a pref.
I've kept the tests that failed enabling the pref because they're
somewhat hard to rewrite and I'd rather avoid that until we know this
will stick, specially since they test the guts of the recursive function
that I'm basically ~disabling.
I've checked that the rendering on those is sensible / matches other
browsers.
Differential Revision: https://phabricator.services.mozilla.com/D130717
Both ScrollToCSSPixels and ScrollByCSSPixels are called only from JS via
Element.scrollTo, Element.scrollTop, Element.scrollLeft, Window.scroll,
Window.scrollTo and Window.scrollBy.
Note that we don't target either Window.scrollByLines or Window.scrollByPages
(both end up calling ScrollFrameHelper::ScrollBy) because both are triggered by
user interactions for our XUL tree implementation, for example
Window.scrollByLines gets called in response to a DOMMouseScroll event in
tree.js [1].
[1] https://searchfox.org/mozilla-central/rev/a12c2c2e59c92d8f969d8f3f290ab16919449c9d/toolkit/content/widgets/tree.js#788
Differential Revision: https://phabricator.services.mozilla.com/D130418
There are 4 call sites of the function, Element::Scroll, Element::SetScrollTop,
Element::SetScrollLeft and nsGlobalWindowInner::ScrollTo. None of call sites
specifies ScrollOrigin.
Differential Revision: https://phabricator.services.mozilla.com/D130416
In the conditions where we hit this partiuclar codepath, the spec used to
require us to align within the grid's padding box (which is what we were trying
to do[1]), but now it requires us to align within the grid's content box.
This patch makes us start passing a bunch of WPT tests (whose .ini files I'm
removing here).
This patch also changes the reference case for some "last-baseline"-specific
tests in the same directory, by cribbing the "alignEnd" rule from the
neighboring non-"last-baseline" analog (since "last-baseline" falls back to end
alignment and is meant to be equivalent in these testcases). Before this
patch, the affected reference cases were inadvertently depending on the Firefox
bug that I'm fixing here, and they were expecting the testcase's end-aligned
content to be at the wrong position as a result. Chromium developers fixed
this issue in the neighboring non-"last-baseline" tests in [2], but they didn't
catch the files that I'm fixing here, because Chromium doesn't implement "last
baseline" alignment yet.
[1] Before this patch, we actually weren't quite aligning within the
padding-box, even though we were trying to. We were computing an alignment
offset based on the size of the padding box, and then we were using that offset
as a position within the *content box*. This could result in us pushing
end-aligned content outside the grid entirely, as in the testcase on the bug
report for this bug.
[2] https://chromium-review.googlesource.com/c/chromium/src/+/2803842
Differential Revision: https://phabricator.services.mozilla.com/D130713
With the rewrite, we reduce the dependency of lwbrk LineBreaker::Next(),
WordBreaker::Next(), and their `int32_t` sentinel values
NS_LINEBREAKER_NEED_MORE_TEXT and NS_WORDBREAKER_NEED_MORE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D130392
With the rewrite, we reduce the dependency of lwbrk LineBreaker::Next(),
WordBreaker::Next(), and their `int32_t` sentinel values
NS_LINEBREAKER_NEED_MORE_TEXT and NS_WORDBREAKER_NEED_MORE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D130392
These are only used for frameset painting and the non-e10s <select>
dropdown focus codepath. We have other more appropriate standard
colors for this.
Differential Revision: https://phabricator.services.mozilla.com/D129992
As we don't support multi-line text in SVG, there's no point running the line-breaker and
collecting potential break positions for textframes that are part of an SVG text subtree.
Telling BuildTextRunsScanner to skip this makes it somewhat less expensive.
In my local build, this reduces the reflow time of the testcase from nearly 20s to about 4.5s.
Still much too long, but at least it's a step in the right direction.
Differential Revision: https://phabricator.services.mozilla.com/D129404
This patch clamps the `resolvedMinSize` before the size is passed into
`UpdateMainMinSize`, which is where the assertion is triggered.
Also, tweak the MOZ_ASSERT a bit because it's best to test an nscoord is
not NS_UNCONSTRAINEDSIZE before invoking comparison operator.
Differential Revision: https://phabricator.services.mozilla.com/D129230
Windows on dark mode uses a semi-transparent selection background like macOS,
which is basically the proton accent color. Avoid totally indistinguishable
backgrounds by ensuring there's at least minimal background contrast when
NS_SAME_AS_FOREGROUND_COLOR is used.
Differential Revision: https://phabricator.services.mozilla.com/D128757
For that:
* Remove support for caching resizer styles, since they don't seem
common enough to warrant it, unlike all other scrollbar parts.
* Make scrollcorners have pointer-events: none with overlay scrollbars,
so that the setup works / we can assert that if we have overlay
scrollbars then we don't care about the pointer-events value on
ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D128772
This code was added in bug 1031107 back when we didn't have apz on desktop, and even on android apz was not reported as enabled because we were using the java pan zoom code (https://bugzilla.mozilla.org/show_bug.cgi?id=1031107#c20).
Looks like the goal of this code was to improve performance when tiling was enabled (splitting up layers into tiles). The code to actually do this tiling appears gone now, so we shouldn't need this.
We can further ask if something might be depending on this code even though it's not related to tiling. The layers.enable.tiles pref is enabled on mac and android, so we'd have bugs on Linux and mac if that were true. Further, the only places that apz is disabled now is popups that do not have remote content in them, and the only scroll frames that are IsAlwaysActive are root scroll frames of root content documents (in process). If addons put an iframe in a popup I think it has to be remote, and I don't think we have any content documents in popups, and if we did and there was a problem with removing that code we'd already have that problem on Linux and Windows. So this should be safe to remove.
Differential Revision: https://phabricator.services.mozilla.com/D127635
This was pre-existing but caught by some scrollbar-width tests. A
test-case that reproduces on current nightly:
data:text/html,<html style="overflow: scroll; scrollbar-color: red red; scrollbar-width: thin">
Toggling the `scrollbar-width` declaration in devtools doesn't change
the effective scrollbar width. Ensure we correctly reflow the scrollbars
in this case.
Differential Revision: https://phabricator.services.mozilla.com/D128515
Use imgINotificationObserver to get notified of size availability.
Layout uses an observer to wait for this too. Our observer is notified
after layout so we should have bounds by then.
We need to store the request status because we get a lot of "replayed"
status changes that would cause chatty and wrong state change events
when the accessible is first created and bound to parent.
We can use that status for both INVISIBLE and ANIMATED states in
NativeState.
Differential Revision: https://phabricator.services.mozilla.com/D127719
`nsTextFragment` is a storage of data node and DOM offset is `uint32_t`, but
some methods of `nsTextFragment` takes `int32_t` for the offset/length in
its text. Therefore, callers need to cast from `uint32_t` to `int32_t` if
the offset value is offset in a DOM node. Therefore, all methods of it should
take `uint32_t` values as offset/length in its text.
Differential Revision: https://phabricator.services.mozilla.com/D127923
Use imgINotificationObserver to get notified of size availability.
Layout uses an observer to wait for this too. Our observer is notified
after layout so we should have bounds by then.
We need to store the request status because we get a lot of "replayed"
status changes that would cause chatty and wrong state change events
when the accessible is first created and bound to parent.
We can use that status for both INVISIBLE and ANIMATED states in
NativeState.
Differential Revision: https://phabricator.services.mozilla.com/D127719
Emilio Cobos Álvarez
Timothy Nikkel
Mathew Hodson
Marian-Vasile Laza
Lee Salzman
Ting-Yu Lin
Nika Layzell
Hector Zhao
Nicolas Silva
Miko Mynttinen
Sebastian Hengst
Norisz Fay
Sean Feng
Andrew Osmond
Iulian Moraru
Markus Stange
James Teh
smolnar
Morgan Reschenberg
Jeff Muizelaar
Emily McDonough
Csoregi Natalia
Hiroyuki Ikezoe
Paul Zuehlcke
Nicklas Boman
Jonathan Kew
Alexandru Michis
Noemi Erli
Dzmitry Malyshau
Daniel Holbert
Neia Finch
Mike Hommey
Kagami Sascha Rosylight
Cristian Tuns
Ryan VanderMeulen
Masayuki Nakano
Boris Chiou
Dan Minor
Butkovits Atila
Greg Tatum
Chris Peterson
Andi-Bogdan Postelnicu
Evgenia Kotovich
criss
Eitan Isaacson
Narcis Beleuzu