Apz can already update the main thread scroll offset if apz has informed the main thread that it has received a scroll animation and is running it.
This situation can happen when the user holds down an arrow key, or in a test situation if one sends a key event every frame via requestAnimateFrame.
The problem happens in APZCCallbackHelper because aFrame->IsScrollAnimating(IncludeApzAnimation::No) returns true so we don't update the main thread scroll offset from the repaint request. aFrame->IsScrollAnimating(IncludeApzAnimation::No) returns true because there is a smooth scroll request either pending on the main thread, or sent in the last transaction, but not yet acknowledged by apz back to the main thread. (Scroll animations that are acknowledged by apz back to the main thread are ignored in IsScrollAnimating because of the IncludeApzAnimation::No argument.)
So we need to change IsScrollAnimating. However there are two other callers of it:
1) ScrollFrameHelper::SaveState (passes IncludeApzAnimation::No)
2) everything else (passes IncludeApzAnimation::Yes)
We can leave 2) alone, but 1) needs the current behaviour of IncludeApzAnimation::No. This is because there are tests that check that we save mDestination (the destination of the smooth scroll) and restore it. However we do not want to save mDestination if IsApzAnimationInProgress because mDestination has already been overwritten with the current scroll position from apz (via APZCCallbackHelper->ScrollToCSSPixelsApproximate).
So we change IncludeApzAnimation::No to ignore all apz animations (what APZCCallbackHelper needs) and introduce a new value of the enum for what SaveState needs.
Differential Revision: https://phabricator.services.mozilla.com/D106757
In bug 1758942 there was a bit of clipping logic for webrenderized svg images that was removed because we didn't know what it was useful for.
I still don't quite know, other than that it caused layout/reftests/svg/image/image-preserveAspectRatio-01-raster.svg and layout/reftests/svg/image/image-preserveAspectRatio-02-raster.svg to start failing when the gfx.webrender.svg-images pref is enabled, so let's revert it.
Depends on D141847
Differential Revision: https://phabricator.services.mozilla.com/D141848
The missing line is consistently called after ImageContainer::GetWidth/GetHeight (see TransformContextForPainting for example which would be the equivalent code path for the non-webrenderized case).
This fixes the wptest /density-size-correction/density-corrected-image-svg.html when active svg images are enabled.
Depends on D141846
Differential Revision: https://phabricator.services.mozilla.com/D141847
In addition to adding test support for dynamic-range and video-dynamic-range,
this expands tests of pixelDepth and colorDepth to allow 30 as an acceptable
value.
Differential Revision: https://phabricator.services.mozilla.com/D141307
In addition to adding test support for dynamic-range and video-dynamic-range,
this expands tests of pixelDepth and colorDepth to allow 30 as an acceptable
value.
Differential Revision: https://phabricator.services.mozilla.com/D141307
For the most part these are simple updates to account for multiple
dictionaries and the fact that SetDictionaries is async whereas
SetDictionary was sync.
Fixing test_async_UpdateCurrentDictionary was more involved because
there were flaws in the existing test and it is more difficult to
harmonize the UpdateCurrentDictionary callback with the changes to make
SetDictionaries async.
Differential Revision: https://phabricator.services.mozilla.com/D140245
The reason why we change the `OMTAdiv`'s width value is that with the original
200px width, the elment in question will be overflowed in our mochitest iframe.
Differential Revision: https://phabricator.services.mozilla.com/D141812
Rename PreferredPopupRect* methods/attributes to MoveToRectPopupRect* ones as it holds info about coordinates received from move-to-rect popup placement done by Wayland compositor.
Differential Revision: https://phabricator.services.mozilla.com/D141425
All platforms seem to behave similarly now. Definitely not like we do
without this patch.
Please sanity-check in case I've missed something but I indeed haven't
seen any current version of other text editing software that behaves
like we do...
Remove some expectAssertions from the test that shouldn't be relevant
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D141635
These methods seem somewhat similar but they have two important differences:
1. Update() only changes the destination, not the current position.
2. ApplyContentShift() does not recompute the shape of the animation curve.
Differential Revision: https://phabricator.services.mozilla.com/D141318
nsDisplayTransform::HitTest clips the rect it passes to its children,
and thus intersecting the whole area isn't relevant.
Depends on D141300
Differential Revision: https://phabricator.services.mozilla.com/D141301
Now that we don't include overflow in outlines (bug 1739894) the
overwhelmingly common case is that innerRect == GetRectRelativeToSelf(),
except on a couple special cases.
Avoid storing the property in those cases. The test introduced in the
patch above still ensures we invalidate rendering correctly even without
the presence of the assert.
Depends on D141320
Differential Revision: https://phabricator.services.mozilla.com/D141321
Before this patch we might not update the ink overflow areas when
'outline-style' changes without changing outline-width, if
'outline-width' was zero.
This was triggered by TopLevelVideoDocument which had 'outline-width: 0'
which before bug 1759602 disabled the default outline.
The test reliably triggers the assertion (though I think we should try
to avoid the frame property in the common case the inner rect and frame
rects just match, which would remove the assertion...).
Differential Revision: https://phabricator.services.mozilla.com/D141320
I wrote the previous code via trial and error by copying similar code without understanding much what the different values represent.
The result looks about right but I suspect it may be only right because of simplifying assumptions.
Differential Revision: https://phabricator.services.mozilla.com/D140726
This doesn't change behavior but makes some code a bit nicer to read and
documents some of the code that wasn't obvious otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D141236
This test runs a lot of JS and triggers a lot of unrelated assertions,
some of which are fatal. The test added in bug 1755790 is much simpler
and a better fit for providing test coverage for the patches in bug
1749190.
Differential Revision: https://phabricator.services.mozilla.com/D141177
This shares code with the transferable / cursor stuff which are the
other two non-rendering callers that deal with images over IPC.
We're going to introduce a consumer of this new type in a second, but
this was worth getting reviewed separately.
Differential Revision: https://phabricator.services.mozilla.com/D141110
Every `VsyncSource` currently only has a single `Display` associated with it.
This means that we're not making use of the `Display` abstraction at all.
This patch gets rid of `Display` by merging it into `VsyncSource`.
Originally, the intention of the `Display` abstraction was to use it for
per-monitor vsync. There would be one software `VsyncSource` and one hardware
`VsyncSource`, and the hardware `VsyncSource` would have one `Display` per
screen. But in reality, things have played out differently: The only platform
with per-monitor vsync is currently Linux Wayland, which has per-**widget**
vsync. And it has chosen to have one `VsyncSource` per widget, with a single
`Display` each.
For the macOS implementation of per-monitor vsync, I think it also makes
sense to have one `VsyncSource` per screen.
We already need to handle switching between VsyncSources, for switching
between software and hardware vsync, if the pref `layout.frame_rate` is
changed. So we might as well reuse that same switching capability for
switching between screens, when a window moves between screens or when a
tab moves between windows on different screens.
Differential Revision: https://phabricator.services.mozilla.com/D140891
IsSyncPagePrinting() only had one implementation which unconditionally
returned true.
So, any code that was conditioned on !IsSyncPagePrinting() is necessarily
dead/unreachable.
These are also crashing due to a null deref in mPrintTarget which might
happen if print is aborted.
Differential Revision: https://phabricator.services.mozilla.com/D140988
See bug 1741740 for a case where this caused issues.
It doesn't react to pointer-events by default so it also makes sense for
it to not be selectable. Also, our selection code doesn't deal
particularly well with anonymous content being selected, specially in a
non-independent selection.
Differential Revision: https://phabricator.services.mozilla.com/D140830
This doesn't in itself make them thread-safe, but it provides a basis to do so by avoiding
dependence on the Preferences service at textrun-construction time.
The FontPrefs record is inert once constructed, so one approach to worker-thread use would
be to make it refcounted, and have the worker hold a strong reference to the record it's using,
so that it won't be affected if the main thread handles a pref-change and replaces its
FontPrefs. Alternatively, maybe we can just protect access with the same lock as other uses
of the font list, once that is in place (bug 1756474).
Differential Revision: https://phabricator.services.mozilla.com/D140914
See bug 1741740 for a case where this caused issues.
It doesn't react to pointer-events by default so it also makes sense for
it to not be selectable. Also, our selection code doesn't deal
particularly well with anonymous content being selected, specially in a
non-independent selection.
Differential Revision: https://phabricator.services.mozilla.com/D140830
We don't currently check whether the geometry has markers, nor do we try to render them properly with WebRender display items.
This is caught by the reftest paint-order-001.svg when active SVG images and rects are enabled.
Differential Revision: https://phabricator.services.mozilla.com/D140808
This patch shouldn't change the behavior.
* It's OK to get the item's offset only when its relatively positioned, because
`ApplyRelativePositioning` doesn't use the offset parameter if the frame is
sticky positioned. Document `ApplyRelativePositioning`'s parameters to clarify
this. Also, we don't need to call apply relative positioning to a
non-relatively-and-non-sticky-positioned item.
* Print `FLEX_LOG` after applying relative-positioning because `aFramePos` will
be adjusted in `ApplyRelativePositioning`, and we really want to see the
item's "final position".
* `aReflowInput` parameter is removed because it's only used to get flex
container's WritingMode. We can get it from FlexItem.
Differential Revision: https://phabricator.services.mozilla.com/D140703
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 might be a bit more controversial, but matches Chromium at least,
and it makes sense to me... Would've also fixed this particular bug,
though I think the previous patch is also desirable if devtools ever
wants to add `:disabled` locked states or so.
Depends on D140529
Differential Revision: https://phabricator.services.mozilla.com/D140530
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
This might be a bit more controversial, but matches Chromium at least,
and it makes sense to me... Would've also fixed this particular bug,
though I think the previous patch is also desirable if devtools ever
wants to add `:disabled` locked states or so.
Depends on D140529
Differential Revision: https://phabricator.services.mozilla.com/D140530
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
What caused the issue was that nsMenuPopupFrame::MoveTo didn't account
for the change in bug 312891. But our context menu / popup positioning
code can be much simpler if we account for the context menu offset
before-hand as an extra horizontal / vertical margin in all directions.
Then we don't need to special-case it at all.
Differential Revision: https://phabricator.services.mozilla.com/D140263
What caused the issue was that nsMenuPopupFrame::MoveTo didn't account
for the change in bug 312891. But our context menu / popup positioning
code can be much simpler if we account for the context menu offset
before-hand as an extra horizontal / vertical margin in all directions.
Then we don't need to special-case it at all.
Differential Revision: https://phabricator.services.mozilla.com/D140263
Also include the raster scale in the PictureKey, so that WR will
invalidate when everything is the same apart from the raster
scale (was causing the included wrench reftest to not re-render).
Differential Revision: https://phabricator.services.mozilla.com/D140282
`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 should be unnecessary, but using vsync priority in non-e10s mode caused
an existing intermittent to become more frequent, see bug 1737709 comment 22.
This special case will go away once mozilla::BrowserTabsRemoteAutostart is removed.
Differential Revision: https://phabricator.services.mozilla.com/D140105
The testcase includes a 1-second pause after the onload event fires, because the test font
includes PNG bitmaps which are asynchronously decoded. This is in theory unreliable,
but for these small images it should be plenty of time (even without any delay, the test
fails only very intermittently) -- if we're failing to decode the images even with the
1-second delay, something is probably truly broken.
(The file svg-bitmap.ttx file is not actually required to run the test, but is the source
for the svg-bitmap.ttf font file, constructed by inserting base64-encoded PNG images
into a minimal font framework.)
Differential Revision: https://phabricator.services.mozilla.com/D140057
The testcase includes a 1-second pause after the onload event fires, because the test font
includes PNG bitmaps which are asynchronously decoded. This is in theory unreliable,
but for these small images it should be plenty of time (even without any delay, the test
fails only very intermittently) -- if we're failing to decode the images even with the
1-second delay, something is probably truly broken.
(The file svg-bitmap.ttx file is not actually required to run the test, but is the source
for the svg-bitmap.ttf font file, constructed by inserting base64-encoded PNG images
into a minimal font framework.)
Differential Revision: https://phabricator.services.mozilla.com/D140057
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
A number of tests (and expectations) are updated here to either avoid
accidentally relying on the size of Courier New on Windows, or to
explicitly use Courier New instead of monospace, where it's harder to
work out how to rewrite the test correctly.
Differential Revision: https://phabricator.services.mozilla.com/D87222
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
Store preferred rect in dev pixels, which simplifies a bit other calculations,
and ensures that the nsMenuPopupFrame code accounts for zoom etc.
Use existing conversion methods for GDK <-> Device <-> CSS conversions.
Differential Revision: https://phabricator.services.mozilla.com/D139623
This change allows IPDL sources to respect FINAL_LIBRARY when building, which
is important for allowing us to build gtest-only IPDL_SOURCES files.
Differential Revision: https://phabricator.services.mozilla.com/D137167
I had this written somewhere in a branch, but given bug 1419151, I
cleaned it up a bit and turned it into an actual patch that works.
Behind a pref for now, because at the very least it needs:
* Support for some testing-only functions.
* Support for custom icons (for web extensions and so on).
The key point is that this adds the relevant code to map a XUL menu to a
GMenuModel, which we could then export via
`g_dbus_connection_export_menu_model()`, which seems like a much simpler
approach to support stuff like bug 1419151.
See the MenuModel class in NativeMenuGtk as for how is this done.
Differential Revision: https://phabricator.services.mozilla.com/D139845
It seems Blink / WebKit run this even if in the same document, but it
seems less-potentially-breaking to restrict this to the cross-document
case.
Though at least on the test-case it seems it's loading from the same
origin, which is a bit dubious to restrict...
Differential Revision: https://phabricator.services.mozilla.com/D138369
Timothy Nikkel
Nicolas Silva
Butkovits Atila
Brad Werth
Marian-Vasile Laza
Dan Minor
Emilio Cobos Álvarez
Hiroyuki Ikezoe
Miko Mynttinen
stransky
Matteo Ruello
Cristian Tuns
Botond Ballo
Jeff Muizelaar
Eitan Isaacson
Daniel Holbert
Narcis Beleuzu
Tooru Fujisawa
Markus Stange
Olli Pettay
Martin Robinson
Jonathan Kew
Mathew Hodson
Sarah Clements
Julien Wajsberg
Masayuki Nakano
Ting-Yu Lin
Iulian Moraru
criss
Mark Banner
Hector Zhao
Glenn Watson
Lee Salzman
Nika Layzell
Jan Varga
Noemi Erli
smolnar
Cameron McCormack
Jonathan Watt
Morgan Reschenberg