Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug 975548: Import minimal frameworks for client #9

Closed
wants to merge 1 commit into from

Conversation

adamroach
Copy link
Contributor

No description provided.

- file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
<html>
<head>
<title></title>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: maybe we want a default title here

@adamroach adamroach closed this Mar 1, 2014
@adamroach adamroach deleted the add-libraries branch March 1, 2014 16:13
rainemak pushed a commit to rainemak/gecko-dev-mirror that referenced this pull request Apr 9, 2014
Don't allow scripts to close windows.
martinthomson added a commit to martinthomson/gecko-dev that referenced this pull request Sep 17, 2014
walac pushed a commit to walac/gecko-dev that referenced this pull request Nov 6, 2014
Bug 1088232 - mach ci-docker-run
rainemak pushed a commit to rainemak/gecko-dev-mirror that referenced this pull request May 11, 2015
…tation

[xulrunner] Add screen rotation API
weilonge pushed a commit to weilonge/gecko-dev that referenced this pull request Nov 10, 2015
fix the bug when trying to get non-exist path's attribute
hwine pushed a commit that referenced this pull request Nov 25, 2015
hwine pushed a commit that referenced this pull request Nov 26, 2015
kuoe0 pushed a commit to kuoe0/gecko-dev that referenced this pull request Dec 3, 2015
kuoe0 pushed a commit to kuoe0/gecko-dev that referenced this pull request Dec 3, 2015
leobalter added a commit to leobalter/gecko-dev that referenced this pull request Jul 20, 2017
# This is the 1st commit message:

Test262 export script

# The commit message #2 will be skipped:

# mock files

# The commit message mozilla#3 will be skipped:

# update reportCompare

# The commit message mozilla#4 will be skipped:

# mock files

# The commit message mozilla#5 will be skipped:

# remove debug

# The commit message mozilla#6 will be skipped:

# mock files

# The commit message mozilla#7 will be skipped:

# capturing reftest directives

# The commit message mozilla#8 will be skipped:

# add todos

# The commit message mozilla#9 will be skipped:

# add todos

# The commit message mozilla#10 will be skipped:

# reportCompare is property parsed
moz-v2v-gh pushed a commit that referenced this pull request Apr 1, 2019
…o clean up Object.prototype, a=testonly

Automatic update from web-platform-tests
IndexedDB: Fix WPT bindings-inject-key to clean up Object.prototype

chromedriver doesn't allow changing Object.prototype to add enumerable
properties, but this test requires setting some values on
Object.prototype.  When Object.prototype.a is set to:

  {b: {c: 'on proto'}}

chromedriver fails with:

    JavascriptErrorException: javascript error (500): Maximum call stack size exceeded
      (Session info: chrome=72.0.3626.121)

    Remote-end stacktrace:

    #0 0x563ff3a32a59 <unknown>
    #1 0x563ff39cb7f3 <unknown>
    #2 0x563ff38fcd7c <unknown>
    #3 0x563ff38ff78c <unknown>
    #4 0x563ff38ff5f7 <unknown>
    #5 0x563ff38ffbe7 <unknown>
    #6 0x563ff38fff1b <unknown>
    #7 0x563ff38a3f7a <unknown>
    #8 0x563ff3899bf2 <unknown>
    #9 0x563ff38a37b7 <unknown>
    #10 0x563ff3899ac3 <unknown>
    #11 0x563ff38782d2 <unknown>
    #12 0x563ff3879112 <unknown>
    #13 0x563ff39fe865 <unknown>
    #14 0x563ff39ff32b <unknown>
    #15 0x563ff39ff70c <unknown>
    #16 0x563ff39d940a <unknown>
    #17 0x563ff39ff997 <unknown>
    #18 0x563ff39e9947 <unknown>
    #19 0x563ff3a1a800 <unknown>
    #20 0x563ff3a3c8be <unknown>
    #21 0x7f3bf4545494 start_thread
    #22 0x7f3bf2d58a8f clone

    Ran 1 tests finished in 2.0 seconds.
      • 0 ran as expected. 0 tests skipped.
      • 1 tests had errors unexpectedly

Work around this problem by cleaning up the test environment so
Object.prototype no longer has the override by the time chromedriver
tries to inspect the test result.

While here, fix the other tests to use the t.add_cleanup() function
so they'll cleanup their test environment in case they exit in
some other way besides reaching t.done().

The underlying chromedriver issue is tracked upstream at
https://crbug.com/chromedriver/2555.

Bug: 934844
Change-Id: Id1b4ab2a908bfbc001e2a2d045eeec3ef01c24d9

--

wpt-commits: 1be74ca2738a05f6e8d98d55ba44c50e3a332554
wpt-pr: 15637
daoshengmu pushed a commit to daoshengmu/gecko-dev that referenced this pull request Apr 4, 2019
…o clean up Object.prototype, a=testonly

Automatic update from web-platform-tests
IndexedDB: Fix WPT bindings-inject-key to clean up Object.prototype

chromedriver doesn't allow changing Object.prototype to add enumerable
properties, but this test requires setting some values on
Object.prototype.  When Object.prototype.a is set to:

  {b: {c: 'on proto'}}

chromedriver fails with:

    JavascriptErrorException: javascript error (500): Maximum call stack size exceeded
      (Session info: chrome=72.0.3626.121)

    Remote-end stacktrace:

    #0 0x563ff3a32a59 <unknown>
    #1 0x563ff39cb7f3 <unknown>
    mozilla#2 0x563ff38fcd7c <unknown>
    mozilla#3 0x563ff38ff78c <unknown>
    mozilla#4 0x563ff38ff5f7 <unknown>
    mozilla#5 0x563ff38ffbe7 <unknown>
    mozilla#6 0x563ff38fff1b <unknown>
    mozilla#7 0x563ff38a3f7a <unknown>
    mozilla#8 0x563ff3899bf2 <unknown>
    mozilla#9 0x563ff38a37b7 <unknown>
    mozilla#10 0x563ff3899ac3 <unknown>
    mozilla#11 0x563ff38782d2 <unknown>
    mozilla#12 0x563ff3879112 <unknown>
    mozilla#13 0x563ff39fe865 <unknown>
    mozilla#14 0x563ff39ff32b <unknown>
    mozilla#15 0x563ff39ff70c <unknown>
    mozilla#16 0x563ff39d940a <unknown>
    mozilla#17 0x563ff39ff997 <unknown>
    mozilla#18 0x563ff39e9947 <unknown>
    mozilla#19 0x563ff3a1a800 <unknown>
    mozilla#20 0x563ff3a3c8be <unknown>
    mozilla#21 0x7f3bf4545494 start_thread
    mozilla#22 0x7f3bf2d58a8f clone

    Ran 1 tests finished in 2.0 seconds.
      • 0 ran as expected. 0 tests skipped.
      • 1 tests had errors unexpectedly

Work around this problem by cleaning up the test environment so
Object.prototype no longer has the override by the time chromedriver
tries to inspect the test result.

While here, fix the other tests to use the t.add_cleanup() function
so they'll cleanup their test environment in case they exit in
some other way besides reaching t.done().

The underlying chromedriver issue is tracked upstream at
https://crbug.com/chromedriver/2555.

Bug: 934844
Change-Id: Id1b4ab2a908bfbc001e2a2d045eeec3ef01c24d9

--

wpt-commits: 1be74ca2738a05f6e8d98d55ba44c50e3a332554
wpt-pr: 15637
moz-v2v-gh pushed a commit that referenced this pull request Nov 29, 2019
…hen there's an override container height, a=testonly

Automatic update from web-platform-tests
[css-flexbox] Don't cache definiteness when there's an override container height

See stack trace below. We set the override container logical height to -1
for the initial layout of a flex item so that we compute the correct size
for min-height. However, that messes with our cache for definite heights
because we would always set it to indefinite in such a case.

Instead, just don't cache these values. That way we will later compute the right
thing for resolving flex-basis, etc.

(FlexNG can't come soon enough...)

 #0  blink::LayoutBox::ContainingBlockLogicalHeightForPercentageResolution (this=0x3dda8d434198,
    out_cb=0x7f6e7d42d8c0, out_skipped_auto_height_containing_block=0x0)
    at ../../third_party/blink/renderer/core/layout/layout_box.cc:3833
 #1  0x00007f6ee84ad0a1 in blink::LayoutFlexibleBox::MainAxisLengthIsDefinite (this=0x3dda8d434010,
    child=..., flex_basis=Length(0%, Percent), add_to_cb=false)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:762
 #2  0x00007f6ee84af930 in blink::LayoutFlexibleBox::MainSizeIsDefiniteForPercentageResolution (
    this=0x3dda8d434010, child=...)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1125
 #3  0x00007f6ee84ad7f5 in blink::LayoutFlexibleBox::UseOverrideLogicalHeightForPerentageResolution (
    this=0x3dda8d434010, child=...)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1137
 #4  0x00007f6ee83f2b9d in blink::LayoutBlock::AvailableLogicalHeightForPercentageComputation (
    this=0x3dda8d434198) at ../../third_party/blink/renderer/core/layout/layout_block.cc:2333
 #5  0x00007f6ee845e745 in blink::LayoutBox::ContainingBlockLogicalHeightForPercentageResolution (
    this=0x3dda8d4243d0, out_cb=0x0, out_skipped_auto_height_containing_block=0x0)
    at ../../third_party/blink/renderer/core/layout/layout_box.cc:3830
 #6  0x00007f6ee86dcc5c in blink::LayoutBoxUtils::AvailableLogicalHeight (box=..., cb=0x3dda8d434198)
    at ../../third_party/blink/renderer/core/layout/ng/layout_box_utils.cc:64
 #7  0x00007f6ee86eafea in blink::LayoutNGMixin<blink::LayoutBlockFlow>::ComputeIntrinsicLogicalWidths (
    this=0x3dda8d4243d0, min_logical_width=0px, max_logical_width=0px)
    at ../../third_party/blink/renderer/core/layout/ng/layout_ng_mixin.cc:48
 #8  0x00007f6ee83ef53a in blink::LayoutBlock::ComputePreferredLogicalWidths (this=0x3dda8d4243d0)
    at ../../third_party/blink/renderer/core/layout/layout_block.cc:1509
 #9  0x00007f6ee8451f01 in blink::LayoutBox::MaxPreferredLogicalWidth (this=0x3dda8d4243d0)
    at ../../third_party/blink/renderer/core/layout/layout_box.cc:1395
 #10 0x00007f6ee84adba2 in blink::LayoutFlexibleBox::ComputeInnerFlexBaseSizeForChild (this=0x3dda8d434198,
    child=..., main_axis_border_and_padding=0px, child_layout_type=blink::LayoutFlexibleBox::kForceLayout)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:890
 #11 0x00007f6ee84ae5d1 in blink::LayoutFlexibleBox::ConstructAndAppendFlexItem (this=0x3dda8d434198,
    algorithm=0x7f6e7d42ed70, child=..., layout_type=blink::LayoutFlexibleBox::kForceLayout)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1203
 #12 0x00007f6ee84aa27b in blink::LayoutFlexibleBox::LayoutFlexItems (this=0x3dda8d434198,
    relayout_children=true, layout_scope=...)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:934
 #13 0x00007f6ee84a9cff in blink::LayoutFlexibleBox::UpdateBlockLayout (this=0x3dda8d434198,
    relayout_children=true) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:369

Bug: 1019138
Change-Id: Ie94e69a5f3fe6accc3623d358315b174088d5597
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1902514
Commit-Queue: David Grogan <dgrogan@chromium.org>
Auto-Submit: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#713296}

--

wpt-commits: 8642cbbba24a10e8a34b4a2720062261f29be5dd
wpt-pr: 20137
moz-v2v-gh pushed a commit that referenced this pull request Jul 15, 2020
Before these changes, ContentChild.h was the #9 most expensive header to include:
217505 ms: /home/simon/work/fuzzy/obj-x86_64-pc-linux-gnu-optimized/dist/include/mozilla/dom/ContentChild.h (included 105 times, avg 2071 ms)

After these changes, it is no longer among the top 30 most expensive headers.

Some missing includes in other files are added along.

Differential Revision: https://phabricator.services.mozilla.com/D83049
moz-v2v-gh pushed a commit that referenced this pull request Aug 24, 2020
StartGamepadMonitoring() can end up in AddGamepad, and acquire the lock
again on the same thread, effectively dead-locking.

This is a regression from bug 1657404. Relevant stack:

    (gdb) bt
    #0  0x00007fd19bace801 in clock_nanosleep@GLIBC_2.2.5 () at /lib64/libc.so.6
    #1  0x00007fd19bad4157 in nanosleep () at /lib64/libc.so.6
    #2  0x00007fd19bad408e in sleep () at /lib64/libc.so.6
    #3  0x00007fd195233e87 in ah_crap_handler(int) (signum=11) at /home/emilio/src/moz/gecko-4/toolkit/xre/nsSigHandlers.cpp:95
    #4  0x00007fd1952165c4 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) (signo=11, info=0x7fd14abb9db0, context=0x7fd14abb9c80) at /home/emilio/src/moz/gecko-4/toolkit/profile/nsProfileLock.cpp:177
    #5  0x00007fd1964973b2 in WasmTrapHandler(int, siginfo_t*, void*) (signum=11, info=<optimized out>, context=<optimized out>) at /home/emilio/src/moz/gecko-4/js/src/wasm/WasmSignalHandlers.cpp:978
    #6  0x00007fd19bf3ca90 in <signal handler called> () at /lib64/libpthread.so.0
    #7  mozilla::detail::MutexImpl::mutexLock() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/mozglue/misc/Mutex_posix.cpp:118
    #8  mozilla::detail::MutexImpl::lock() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/mozglue/misc/Mutex_posix.cpp:142
    #9  0x00007fd190cc795a in mozilla::OffTheBooksMutex::Lock() (this=0x7fd136649398) at /home/emilio/src/moz/gecko-4/xpcom/threads/BlockingResourceBase.cpp:318
    #10 0x00007fd19326e65e in mozilla::detail::BaseAutoLock<mozilla::Mutex&>::BaseAutoLock(mozilla::Mutex&) (this=<optimized out>, aLock=...) at /home/emilio/src/moz/gecko-4/obj-debug-no-sccache/dist/include/mozilla/Mutex.h:159
    #11 mozilla::dom::GamepadPlatformService::NotifyGamepadChange<mozilla::dom::GamepadAdded>(unsigned int, mozilla::dom::GamepadAdded const&) (this=0x7fd136649380, aIndex=1, aInfo=...)
        at /home/emilio/src/moz/gecko-4/dom/gamepad/GamepadPlatformService.cpp:65
    #12 0x00007fd193269178 in mozilla::dom::GamepadPlatformService::AddGamepad(char const*, mozilla::dom::GamepadMappingType, mozilla::dom::GamepadHand, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int)
        (this=0x7fd136649380, aID=<optimized out>, aMapping=mozilla::dom::GamepadMappingType::_empty, aHand=mozilla::dom::GamepadHand::_empty, aNumButtons=11, aNumAxes=8, aHaptics=0, aNumLightIndicator=0, aNumTouchEvents=0)
        at /home/emilio/src/moz/gecko-4/dom/gamepad/GamepadPlatformService.cpp:96
    #13 0x00007fd19326de4a in (anonymous namespace)::LinuxGamepadService::AddDevice(mozilla::udev_device*) (this=<optimized out>, dev=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:139
    #14 0x00007fd19326a156 in (anonymous namespace)::LinuxGamepadService::ScanForDevices() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:188
    #15 (anonymous namespace)::LinuxGamepadService::Startup() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:233
    #16 mozilla::dom::StartGamepadMonitoring() () at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:334
    #17 0x00007fd193269c6b in mozilla::dom::GamepadPlatformService::AddChannelParent(mozilla::dom::GamepadEventChannelParent*) (this=<optimized out>, aParent=<optimized out>)
        at /home/emilio/src/moz/gecko-4/dom/gamepad/GamepadPlatformService.cpp:225
    #18 0x00007fd19326d175 in mozilla::dom::GamepadEventChannelParent::Init() (this=0x7fd136e76a00) at /home/emilio/src/moz/gecko-4/dom/gamepad/ipc/GamepadEventChannelParent.cpp:50
    #19 0x00007fd1913ba3a6 in mozilla::ipc::BackgroundParentImpl::RecvPGamepadEventChannelConstructor(mozilla::dom::PGamepadEventChannelParent*) (this=0x7fd13f888000, aActor=0x0)
        at /home/emilio/src/moz/gecko-4/ipc/glue/BackgroundParentImpl.cpp:1109
    #20 0x00007fd1917c7da1 in mozilla::ipc::PBackgroundParent::OnMessageReceived(IPC::Message const&) (this=0x7fd13f888000, msg__=...) at PBackgroundParent.cpp:4967
    #21 0x00007fd1913ea71d in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) (this=0x7fd13f8880f8, aProxy=0x7fd13ff48140, aMsg=...)

Differential Revision: https://phabricator.services.mozilla.com/D87967
moz-v2v-gh pushed a commit that referenced this pull request Aug 25, 2020
… a=RyanVM

StartGamepadMonitoring() can end up in AddGamepad, and acquire the lock
again on the same thread, effectively dead-locking.

This is a regression from bug 1657404. Relevant stack:

    (gdb) bt
    #0  0x00007fd19bace801 in clock_nanosleep@GLIBC_2.2.5 () at /lib64/libc.so.6
    #1  0x00007fd19bad4157 in nanosleep () at /lib64/libc.so.6
    #2  0x00007fd19bad408e in sleep () at /lib64/libc.so.6
    #3  0x00007fd195233e87 in ah_crap_handler(int) (signum=11) at /home/emilio/src/moz/gecko-4/toolkit/xre/nsSigHandlers.cpp:95
    #4  0x00007fd1952165c4 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) (signo=11, info=0x7fd14abb9db0, context=0x7fd14abb9c80) at /home/emilio/src/moz/gecko-4/toolkit/profile/nsProfileLock.cpp:177
    #5  0x00007fd1964973b2 in WasmTrapHandler(int, siginfo_t*, void*) (signum=11, info=<optimized out>, context=<optimized out>) at /home/emilio/src/moz/gecko-4/js/src/wasm/WasmSignalHandlers.cpp:978
    #6  0x00007fd19bf3ca90 in <signal handler called> () at /lib64/libpthread.so.0
    #7  mozilla::detail::MutexImpl::mutexLock() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/mozglue/misc/Mutex_posix.cpp:118
    #8  mozilla::detail::MutexImpl::lock() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/mozglue/misc/Mutex_posix.cpp:142
    #9  0x00007fd190cc795a in mozilla::OffTheBooksMutex::Lock() (this=0x7fd136649398) at /home/emilio/src/moz/gecko-4/xpcom/threads/BlockingResourceBase.cpp:318
    #10 0x00007fd19326e65e in mozilla::detail::BaseAutoLock<mozilla::Mutex&>::BaseAutoLock(mozilla::Mutex&) (this=<optimized out>, aLock=...) at /home/emilio/src/moz/gecko-4/obj-debug-no-sccache/dist/include/mozilla/Mutex.h:159
    #11 mozilla::dom::GamepadPlatformService::NotifyGamepadChange<mozilla::dom::GamepadAdded>(unsigned int, mozilla::dom::GamepadAdded const&) (this=0x7fd136649380, aIndex=1, aInfo=...)
        at /home/emilio/src/moz/gecko-4/dom/gamepad/GamepadPlatformService.cpp:65
    #12 0x00007fd193269178 in mozilla::dom::GamepadPlatformService::AddGamepad(char const*, mozilla::dom::GamepadMappingType, mozilla::dom::GamepadHand, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int)
        (this=0x7fd136649380, aID=<optimized out>, aMapping=mozilla::dom::GamepadMappingType::_empty, aHand=mozilla::dom::GamepadHand::_empty, aNumButtons=11, aNumAxes=8, aHaptics=0, aNumLightIndicator=0, aNumTouchEvents=0)
        at /home/emilio/src/moz/gecko-4/dom/gamepad/GamepadPlatformService.cpp:96
    #13 0x00007fd19326de4a in (anonymous namespace)::LinuxGamepadService::AddDevice(mozilla::udev_device*) (this=<optimized out>, dev=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:139
    #14 0x00007fd19326a156 in (anonymous namespace)::LinuxGamepadService::ScanForDevices() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:188
    #15 (anonymous namespace)::LinuxGamepadService::Startup() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:233
    #16 mozilla::dom::StartGamepadMonitoring() () at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:334
    #17 0x00007fd193269c6b in mozilla::dom::GamepadPlatformService::AddChannelParent(mozilla::dom::GamepadEventChannelParent*) (this=<optimized out>, aParent=<optimized out>)
        at /home/emilio/src/moz/gecko-4/dom/gamepad/GamepadPlatformService.cpp:225
    #18 0x00007fd19326d175 in mozilla::dom::GamepadEventChannelParent::Init() (this=0x7fd136e76a00) at /home/emilio/src/moz/gecko-4/dom/gamepad/ipc/GamepadEventChannelParent.cpp:50
    #19 0x00007fd1913ba3a6 in mozilla::ipc::BackgroundParentImpl::RecvPGamepadEventChannelConstructor(mozilla::dom::PGamepadEventChannelParent*) (this=0x7fd13f888000, aActor=0x0)
        at /home/emilio/src/moz/gecko-4/ipc/glue/BackgroundParentImpl.cpp:1109
    #20 0x00007fd1917c7da1 in mozilla::ipc::PBackgroundParent::OnMessageReceived(IPC::Message const&) (this=0x7fd13f888000, msg__=...) at PBackgroundParent.cpp:4967
    #21 0x00007fd1913ea71d in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) (this=0x7fd13f8880f8, aProxy=0x7fd13ff48140, aMsg=...)

Differential Revision: https://phabricator.services.mozilla.com/D87967
moz-v2v-gh pushed a commit that referenced this pull request Sep 9, 2020
…efs that could affect font inflation change. r=kats

When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert

```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#01: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#2: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#3: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#4: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#5: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#6: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#7: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#8: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#9: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```

This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.

Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.

Differential Revision: https://phabricator.services.mozilla.com/D89409
moz-v2v-gh pushed a commit that referenced this pull request Sep 11, 2020
The test fixes all fell into the follow categories:

A) The test uses requestAnimationFrame to wait one frame and expects scrolling to be complete. With the desktop zooming scrollbars in order for the scrolling to show up on the main thread we need to send the scroll request to the compositor and then hear back from it via an apz repaint request (apz callback helper). Waiting on requestAnimationFrame will complete the first part, but not necessarily the second part. The fix is to wait for a scroll event.

B) Switching tests to wait for scroll events exposes another problem: the test can do things that cause a scroll in order to setup the test (and that may not be obvious that it causes a scroll) before actually proceeding to do the test and do something that causes a scroll and then checks for the scroll change of the second thing. Waiting for a requestAnimationFrame would include both those scrolls without desktop zooming scrollbars, but if we wait for a scroll event we will get the scroll event for the first thing which we are not interested in. So we need to make sure scroll events are cleared out before waiting for any scroll events. We do this by waiting two requestAnimationFrame's and waiting for apz to be flushed. We also use this when a test does something and it wants to test that scrolling is not performed.

The main thing that causes scrolling that may not be obvious: calling node.focus(). With stacks like:

from test_scroll_per_page.html

```
#01: mozilla::ScrollFrameHelper::CompleteAsyncScroll(nsRect const&, mozilla::ScrollOrigin) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d6cc0]
#2: mozilla::ScrollFrameHelper::ScrollToWithOrigin(nsPoint, mozilla::ScrollMode, mozilla::ScrollOrigin, nsRect const*, nsIScrollbarMediator::ScrollSnapMode) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d7732]
#3: mozilla::layout::ScrollAnchorContainer::ApplyAdjustments() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4742913]
#4: mozilla::PresShell::FlushPendingScrollAnchorAdjustments() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4650069]
#5: mozilla::PresShell::ProcessReflowCommands(bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x465742b]
#6: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4656af8]
#7: mozilla::dom::Document::FlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1a87d3c]
#8: mozilla::PresShell::ScrollContentIntoView(nsIContent*, mozilla::ScrollAxis, mozilla::ScrollAxis, mozilla::ScrollFlags) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4652b96]
#9: nsFocusManager::ScrollIntoView(mozilla::PresShell*, nsIContent*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1bedd1c]
#10: nsFocusManager::Focus(nsPIDOMWindowOuter*, mozilla::dom::Element*, unsigned int, bool, bool, bool, bool, bool, nsIContent*) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be6be0]
#11: nsFocusManager::SetFocusInner(mozilla::dom::Element*, int, bool, bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be212f]
#12: nsFocusManager::SetFocus(mozilla::dom::Element*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be32ba]
#13: mozilla::dom::Element::Focus(mozilla::dom::FocusOptions const&, mozilla::dom::CallerType, mozilla::ErrorResult&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1aaf283]
#14: mozilla::dom::HTMLElement_Binding::focus(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x2d65f3b]
```

from editor/libeditor/tests/test_bug549262.html

```
#01: mozilla::ScrollFrameHelper::CompleteAsyncScroll(nsRect const&, mozilla::ScrollOrigin) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d6cc0]
#2: mozilla::ScrollFrameHelper::ScrollToWithOrigin(nsPoint, mozilla::ScrollMode, mozilla::ScrollOrigin, nsRect const*, nsIScrollbarMediator::ScrollSnapMode) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d7732]
#3: mozilla::PresShell::ScrollFrameRectIntoView(nsIFrame*, nsRect const&, mozilla::ScrollAxis, mozilla::ScrollAxis, mozilla::ScrollFlags) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x46541bc]
#4: mozilla::PresShell::DoScrollContentIntoView() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4653776]
#5: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4656b11]
#6: mozilla::dom::Document::FlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1a87d3c]
#7: mozilla::PresShell::ScrollContentIntoView(nsIContent*, mozilla::ScrollAxis, mozilla::ScrollAxis, mozilla::ScrollFlags) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4652b96]
#8: nsFocusManager::ScrollIntoView(mozilla::PresShell*, nsIContent*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1bedd1c]
#9: nsFocusManager::Focus(nsPIDOMWindowOuter*, mozilla::dom::Element*, unsigned int, bool, bool, bool, bool, bool, nsIContent*) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be6be0]
#10: nsFocusManager::SetFocusInner(mozilla::dom::Element*, int, bool, bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be212f]
#11: nsFocusManager::SetFocus(mozilla::dom::Element*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be32ba]
#12: mozilla::dom::Element::Focus(mozilla::dom::FocusOptions const&, mozilla::dom::CallerType, mozilla::ErrorResult&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1aaf283]
#13: mozilla::dom::HTMLElement_Binding::focus(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x2d65f3b]
```

C) Several tests use nsIDOMWindowUtils advanceTimeAndRefresh/restoreNormalRefresh and expect scrolling to be done after a call to advanceTimeAndRefresh. This is basically A), advanceTimeAndRefresh does a refresh driver tick but doesn't allow a repaint request to come back to the main thread.

Differential Revision: https://phabricator.services.mozilla.com/D89403
moz-v2v-gh pushed a commit that referenced this pull request Sep 15, 2020
…efs that could affect font inflation change. r=kats

When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert

```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#01: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#2: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#3: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#4: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#5: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#6: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#7: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#8: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#9: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```

This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.

Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.

Differential Revision: https://phabricator.services.mozilla.com/D89409
moz-v2v-gh pushed a commit that referenced this pull request Sep 15, 2020
…efs that could affect font inflation change. r=kats

When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert

```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#01: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#2: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#3: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#4: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#5: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#6: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#7: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#8: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#9: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```

This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.

Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.

Differential Revision: https://phabricator.services.mozilla.com/D89409
moz-v2v-gh pushed a commit that referenced this pull request Jun 2, 2021
Here's what's going on (relevant browser is browser 36).

[rr 502130 274898]RestoreDocShellState(browser=36, bc=94, )
[rr 502130 274902]RemoteWebNavigation.currentURI browser=36 bc=94 http://mochi.test:8888/#1
[rr 502130 274906]BrowsingContext::LoadURI(browser=36, bc=94, about:blank)

  From a previous restore we correctly wait for:

    0 _restoreTabContent(    <Failed to get argument while inspecting stack frame>
      <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":5984:30]
        <failed to get 'this' value>
    1 _sendRestoreTabContent(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":6002:11]
        <failed to get 'this' value>
    2 restoreTabContent(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4684:9]
        <failed to get 'this' value>
    3 restoreTab(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4565:13]
        <failed to get 'this' value>
    4 restoreTabs(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    aSelectTab = "1") ["resource:///modules/sessionstore/SessionStore.jsm":4413:11]
        <failed to get 'this' value>
    5 ssi_restoreWindow(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4189:11]
        <failed to get 'this' value>
    6 _restoreWindowsFeaturesAndTabs(    <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4275:11]
        <failed to get 'this' value>
    7 _restoreWindowsInReversedZOrder(    <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4299:9]
        <failed to get 'this' value>
    8 ssi_restoreWindows/<(    <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4359:11]

[rr 502506 275264]BrowsingContext::LoadURI(browser=36, bc=94, about:blank)
[rr 502506 275268]DocumentChannelChild::AsyncOpen(browser=36, bc=94, about:blank)
[rr 502130 275388]RemoteWebNavigation.currentURI browser=36 bc=94 http://mochi.test:8888/#1
[rr 502506 275629]BrowserChild::OnLocationChange(browser=36, bc=94, about:blank)
[rr 502130 276944]updateForLocationChange browser=36 bc=94 - about:blank
[rr 502130 277084]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 277358]RestoreDocShellState(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502506 277378]BrowserChild::OnLocationChange(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502130 277390]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 277554]BrowserParent::LoadURL(browser=36, bc=94, about:blank)

From:

    #18 0x00007ff0bdb1efcc in mozilla::dom::BrowserParent::LoadURL(nsDocShellLoadState*) (this=0x7ff08f2b9800, aLoadState=0x7ff094e1d580) at /home/emilio/src/moz/gecko/dom/ipc/BrowserParent.cpp:861
    #19 0x00007ff0bc1117f9 in nsFrameLoader::ReallyStartLoadingInternal() (this=0x7ff08f283400) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoader.cpp:718
    #20 0x00007ff0bc11129f in nsFrameLoader::ReallyStartLoading() (this=0x7ff08f283400) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoader.cpp:640
    #21 0x00007ff0bc0002f5 in mozilla::dom::Document::MaybeInitializeFinalizeFrameLoaders() (this=0x7ff0a17e2000) at /home/emilio/src/moz/gecko/dom/base/Document.cpp:9008
    #22 0x00007ff0bc057891 in mozilla::detail::RunnableMethodArguments<>::applyImpl<mozilla::dom::Document, void (mozilla::dom::Document::*)()>(mozilla::dom::Document*, void (mozilla::dom::Document::*)(), mozilla::Tuple<>&, std::integer_sequence<unsigned long>) (o=<optimized out>, m=<optimized out>, args=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1150
    #23 mozilla::detail::RunnableMethodArguments<>::apply<mozilla::dom::Document, void (mozilla::dom::Document::*)()>(mozilla::dom::Document*, void (mozilla::dom::Document::*)()) (this=<optimized out>, o=<optimized out>, m=<optimized out>)
        at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1156
    #24 mozilla::detail::RunnableMethodImpl<mozilla::dom::Document*, void (mozilla::dom::Document::*)(), true, (mozilla::RunnableKind)0>::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1203
    #25 0x00007ff0bbef8209 in nsContentUtils::RemoveScriptBlocker() () at /home/emilio/src/moz/gecko/dom/base/nsContentUtils.cpp:5696
    #26 0x00007ff0bc11c427 in nsAutoScriptBlocker::~nsAutoScriptBlocker() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsContentUtils.h:3499
    #27 nsFrameLoaderOwner::ChangeRemotenessCommon(nsFrameLoaderOwner::ChangeRemotenessContextType const&, mozilla::dom::RemotenessChangeOptions const&, bool, bool, mozilla::dom::BrowsingContextGroup*, std::function<void ()>&, mozilla::ErrorResult&) (this=<optimized out>, this@entry=0x7ff0a041b608, aContextType=@0x7ffe238847fc: nsFrameLoaderOwner::ChangeRemotenessContextType::PRESERVE, aOptions=
        ..., aSwitchingInProgressLoad=false, aIsRemote=<optimized out>, aGroup=<optimized out>, aGroup@entry=0x0, aFrameLoaderInit=..., aRv=...) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoaderOwner.cpp:191
    #28 0x00007ff0bc11c81f in nsFrameLoaderOwner::ChangeRemoteness(mozilla::dom::RemotenessOptions const&, mozilla::ErrorResult&) (this=0x7ff0a041b608, aOptions=..., rv=...) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoaderOwner.cpp:250
    #29 0x00007ff0bcb59003 in mozilla::dom::XULFrameElement_Binding::changeRemoteness(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&)Traceback (most recent call last):
      File "/home/emilio/src/moz/gecko/js/src/gdb/mozilla/Root.py", line 55, in to_string
        ptr = ptr.dereference()
    gdb.error: value has been optimized out
     (cx_=<optimized out>, obj=
    , void_self=<optimized out>, args=...) at XULFrameElementBinding.cpp:513
    #30 0x00007ff0bcecc02a in mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) (cx=0x1,
        cx@entry=0x7ff0a871b000, argc=<optimized out>, vp=<optimized out>) at /home/emilio/src/moz/gecko/dom/bindings/BindingUtils.cpp:3297
    #31 0x00007ff0bf67b1f1 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)

From:

    0 updateBrowserRemoteness(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["chrome://browser/content/tabbrowser.js":1937:15]
        <failed to get 'this' value>
    1 updateBrowserRemotenessByURL(    <Failed to get argument while inspecting stack frame>
    aURL = ""http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html"") ["chrome://browser/content/tabbrowser.js":2052:20]
        <failed to get 'this' value>
    2 restoreTabContent(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4662:38]
        <failed to get 'this' value>
    3 restoreTab(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4565:13]
        <failed to get 'this' value>
    4 restoreTabs(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    aSelectTab = "2") ["resource:///modules/sessionstore/SessionStore.jsm":4413:11]
        <failed to get 'this' value>
    5 ssi_restoreWindow(    <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
        <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4189:11]
        <failed to get 'this' value>
    6 _restoreWindowsFeaturesAndTabs(    <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4275:11]
        <failed to get 'this' value>
    7 _restoreWindowsInReversedZOrder(    <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4299:9]
        <failed to get 'this' value>
    8 ssi_restoreWindows/<(    <Failed to get argument while inspecting stack frame>
    ) ["resource:///modules/sessionstore/SessionStore.jsm":4359:11]

This load triggers a remoteness change.

[rr 502130 277558]RemoteWebNavigation.currentURI browser=36 bc=94 undefined
[rr 502130 277561]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 277564]RestoreDocShellState(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502130 277568]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 277572]BrowsingContext::LoadURI(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)

This is the load that should actually end up in the browsing context.

[rr 502578 280053]DocumentChannelChild::AsyncOpen(browser=36, bc=94, about:blank)

From the previous remoteness update.

[rr 502130 280138]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 280141]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 280143]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank
[rr 502130 280146]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank

At this point, we try to use the BFCache, and end up replacing the
browsing context:

    #0  mozilla::dom::CanonicalBrowsingContext::AllowedInBFCache(mozilla::Maybe<unsigned long> const&) (this=0x7ff08f2b5800, aChannelId=...) at /home/emilio/src/moz/gecko/docshell/base/CanonicalBrowsingContext.cpp:2158
    #1  0x00007ff0bb3157c1 in mozilla::net::DocumentLoadListener::MaybeTriggerProcessSwitch(bool*) (this=this@entry=0x7ff093b74090, aWillSwitchToRemote=aWillSwitchToRemote@entry=0x7ffe23887838)
        at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:1723
    #2  0x00007ff0bb317feb in mozilla::net::DocumentLoadListener::OnStartRequest(nsIRequest*) (this=0x7ff093b74090, aRequest=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:2263
    #3  0x00007ff0bb238a0c in mozilla::net::ParentChannelListener::OnStartRequest(nsIRequest*) (this=0x7ff08d5c4ee0, aRequest=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/protocol/http/ParentChannelListener.cpp:91
    #4  0x00007ff0bb9abec2 in nsDocumentOpenInfo::OnStartRequest(nsIRequest*) (this=<optimized out>, request=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:166
    #5  0x00007ff0bb32baf0 in mozilla::net::ParentProcessDocumentOpenInfo::OnDocumentStartRequest(nsIRequest*) (this=0x7ff093bc5b80, request=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:292
    #6  0x00007ff0bae6446c in nsBaseChannel::OnStartRequest(nsIRequest*) (this=<optimized out>, request=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/base/nsBaseChannel.cpp:833
    #7  0x00007ff0bae82bdd in nsInputStreamPump::OnStateStart() (this=this@entry=0x7ff08f2593c0) at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:481
    #8  0x00007ff0bae828d9 in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (this=0x7ff08f2593c0, stream=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:390
    #9  0x00007ff0bae8339b in non-virtual thunk to nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) () at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:632
    #10 0x00007ff0bacd29d5 in mozilla::NonBlockingAsyncInputStream::RunAsyncWaitCallback(mozilla::NonBlockingAsyncInputStream::AsyncWaitRunnable*, already_AddRefed<nsIInputStreamCallback>)
        (this=this@entry=0x7ff094eb5a50, aRunnable=aRunnable@entry=0x7ff08f228560, aCallback=...) at /home/emilio/src/moz/gecko/xpcom/io/NonBlockingAsyncInputStream.cpp:397
    #11 0x00007ff0bacdf2ec in mozilla::NonBlockingAsyncInputStream::AsyncWaitRunnable::Run() (this=0x7ff08f228560) at /home/emilio/src/moz/gecko/xpcom/io/NonBlockingAsyncInputStream.cpp:33
    #12 0x00007ff0bad48d04 in mozilla::RunnableTask::Run() (this=0x7ff093bc5980) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:482
    #13 0x00007ff0bad316d4 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (this=<optimized out>, this@entry=0x7ff0c54f2400, aProofOfLock=...)
        at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:766
    #14 0x00007ff0bad3091d in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (this=this@entry=0x7ff0c54f2400, aProofOfLock=...)
        at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:621
    #15 0x00007ff0bad30a83 in mozilla::TaskController::ProcessPendingMTTask(bool) (this=0x7ff0c54f2400, aMayWait=false) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:405
    #16 0x00007ff0bad4388f in mozilla::TaskController::InitializeInternal()::$_0::operator()() const (this=<optimized out>) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:138
    #17 mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_0>::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:534
    #18 0x00007ff0bad3b7f6 in nsThread::ProcessNextEvent(bool, bool*) (this=0x7ff0c541d680, aMayWait=false, aResult=0x7ffe23888437) at /home/emilio/src/moz/gecko/xpcom/threads/nsThread.cpp:1159
    #19 0x00007ff0bad3f384 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x7ff08f2b5800, aThread@entry=0x7ff0c541d680, aMayWait=false) at /home/emilio/src/moz/gecko/xpcom/threads/nsThreadUtils.cpp:548
    #20 0x00007ff0bb43dfe0 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7ff0c54d12c0, aDelegate=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/glue/MessagePump.cpp:85
    #21 0x00007ff0bb3be7b7 in MessageLoop::RunInternal() (this=this@entry=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:335
    #22 0x00007ff0bb3be707 in MessageLoop::RunHandler() (this=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:328
    #23 MessageLoop::Run() (this=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:310
    #24 0x00007ff0bded2bdb in nsBaseAppShell::Run() (this=0x7ff0a880c580) at /home/emilio/src/moz/gecko/widget/nsBaseAppShell.cpp:137
    #25 0x00007ff0bf449d85 in nsAppStartup::Run() (this=0x7ff0a883de20) at /home/emilio/src/moz/gecko/toolkit/components/startup/nsAppStartup.cpp:273
    #26 0x00007ff0bf5428b6 in XREMain::XRE_mainRun() (this=<optimized out>, this@entry=0x7ffe238887c0) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5239
    #27 0x00007ff0bf5433ef in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (this=this@entry=0x7ffe238887c0, argc=argc@entry=5, argv=argv@entry=0x7ffe23889a68, aConfig=<optimized out>)
        at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5437
    #28 0x00007ff0bf54385e in XRE_main(int, char**, mozilla::BootstrapConfig const&) (argc=-1816706824, argv=0x7ff0c56441a0, aConfig=...) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5496
    #29 0x0000562d08f8e415 in do_main(int, char**, char**) (argc=-1816706824, argv=0x7ffe23889a68, envp=<optimized out>) at /home/emilio/src/moz/gecko/browser/app/nsBrowserApp.cpp:224

[rr 502130 280199]CanonicalBrowsingContext::ReplacedBy(94 -> 104)
[rr 502130 280344]didChangeRemoteness browser=36, bc=104
[rr 502130 280348]RemoteWebNavigation.currentURI browser=36 bc=104 undefined
[rr 502130 280625]RedirectToRealChannel(36, about:blank)
[rr 502578 280695]BrowserChild::OnLocationChange(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502578 280699]BrowsingContext::LoadURI(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)
[rr 502578 280703]DocumentChannelChild::AsyncOpen(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html)

    This is the LoadURI call for the "final" load, however it went to
    the wrong browsing context, as we just replaced this!

[rr 502130 280803]updateForLocationChange browser=36 bc=104 - http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html
[rr 502130 280807]RemoteWebNavigation.currentURI browser=36 bc=104 http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html
[rr 502578 281334]BrowserChild::OnLocationChange(browser=36, bc=104, about:blank)

    And this one is from the process switch.

[rr 502130 281461]updateForLocationChange browser=36 bc=104 - about:blank
[rr 502130 281465]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank
[rr 502130 282028]
ⰲ겿{"action":"test_status","time":1621467211822,"thread":null,"pid":null,"source":"mochitest","test":"chrome://mochitests/content/browser/browser/base/content/test/tabs/browser_new_tab_insert_position.js","subtest":"tab pos 0 matched http://mochi.test:8888/#0","status":"PASS","message":"","js_source":"TestRunner.js"}ⰲ겿
[rr 502130 282031]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank
[rr 502130 282033]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank
[rr 502130 282117]

So this is certainly the easy fix, but I think we should generally try
to deal with this better, somehow?

Differential Revision: https://phabricator.services.mozilla.com/D115560
moz-v2v-gh pushed a commit that referenced this pull request Nov 2, 2021
…tions., a=testonly

Automatic update from web-platform-tests
[CSP]: Do not block same-document navigations.

A cross-origin initiated same-document navigation caused crash when
blocked by CSP.

Stop blocking it + WPT regression test.

This is #9 Mac crasher on M95 stable. So expect M96 (beta) cherry-pick.
That's probably not enough for cherry-pick M95 (stable).

Bug: 1262203
Change-Id: Ie70f77bd9ec69ac0659321f2e8e626b2bd091126
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3247135
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Antonio Sartori <antoniosartori@chromium.org>
Cr-Commit-Position: refs/heads/main@{#935920}

--

wpt-commits: 038de3e0ddeaf9e20bb3074a270b558559927add
wpt-pr: 31413
luyahan added a commit to luyahan/gecko-dev that referenced this pull request Aug 25, 2022
* Implement part macroassembler

* fix error
ChunMinChang added a commit to ChunMinChang/gecko-dev that referenced this pull request Jun 2, 2023
```js
let lastDequeueSize = Infinity;
decoder.ondequeue = () => {
  assert_greater_than(lastDequeueSize, 0, "Dequeue event after queue empty");
  assert_greater_than(lastDequeueSize, decoder.decodeQueueSize,
                      "Dequeue event without decreased queue size");
  lastDequeueSize = decoder.decodeQueueSize;
};
```

The above checkes doesn't really work since the VideoDecoder's
codec-work-queue runs in parallel with the VideoDecoder interface. The
dequeue events can arrive after the last dequeue size has been 0 if the
work queue decodes multiple samples while VideoDecoder is processing
just one dequeue event. Besides, `decodeQueueSize` can change between
the two `decoder.decodeQueueSize` calls since it can be mutated on both
VideoDecoder's owner thread and the codec-work-queue thread. As a
result, these two `decodeQueueSize` can be different, and the
`lastDequeueSize` is not guaranteed to be decreased one at a time per
event, even if the internal decodeQueueSize is decreased one at a time
(on codec-work-queue thread). The value can be decreased more than one
at a time.

The following example demonstrates one case when those checks can fail.

Suppose VideoDecoder *D* runs on thread *T* (main or worker) and
codec-work-queue runs on thread *Q*. In the test, by the time
VideoDecoder is `configure`d successfully and `decode` request are sent,
the codec-work-queue is ready to `decode` the pending samples. Below
illustrates why the wpt checks in the begining don't work

Q) The underlying codec is configured, ready to decode sample #1.
   Schedule a dequeue event. The current queue size is 9.
T) Get a dequeue event #1. Now D.decodeQueueSize is 9.
Q) Decode sample #1 succeeded, ready to decode sample mozilla#2. Schedule a
   dequeue event. The current queue size is 8.
T) `D.decode()` for sample #1 succeeded. Get VideoFrame #1.
T) Get a dequeue event mozilla#2. Now D.decodeQueueSize is 8.
Q) Decode sample mozilla#2 succeeded, ready to decode sample mozilla#3. Schedule a
   dequeue event. The current queue size is 7.
T) `D.decode()` for sample mozilla#2 succeeded. Get VideoFrame mozilla#2.
Q) Decode sample mozilla#3 succeeded, ready to decode sample mozilla#4. Schedule a
   dequeue event. The current queue size is 6.
Q) Decode sample mozilla#4 succeeded, ready to decode sample mozilla#5. Schedule a
   dequeue event. The current queue size is 5.
T) Get a dequeue event mozilla#3. Now D.decodeQueueSize is 5.
T) `D.decode()` for sample mozilla#3 succeeded. Get VideoFrame mozilla#3.
T) Get a dequeue event mozilla#4. Now D.decodeQueueSize is 5.
   => "Dequeue event without decreased queue size" fails here
Q) Decode sample mozilla#5 succeeded, ready to decode sample mozilla#6. Schedule a
   dequeue event. The current queue size is 4.
Q) Decode sample mozilla#6 succeeded, ready to decode sample mozilla#7. Schedule a
   dequeue event. The current queue size is 3.
Q) Decode sample mozilla#7 succeeded, ready to decode sample mozilla#8. Schedule a
   dequeue event. The current queue size is 2.
T) `D.decode()` for sample mozilla#4 succeeded. Get VideoFrame mozilla#4.
T) Get a dequeue event mozilla#5. Now D.decodeQueueSize is 2.
T) `D.decode()` for sample mozilla#5 succeeded. Get VideoFrame mozilla#5.
T) Get a dequeue event mozilla#6. Now D.decodeQueueSize is 2.
   => "Dequeue event without decreased queue size" fails again here
Q) Decode sample mozilla#8 succeeded, ready to decode sample mozilla#9. Schedule a
   dequeue event. The current queue size is 1.
T) `D.decode()` for sample mozilla#6 succeeded. Get VideoFrame mozilla#6.
Q) Decode sample mozilla#9 succeeded, ready to decode sample mozilla#10. Schedule a
   dequeue event. The current queue size is 0.
T) Get a dequeue event mozilla#7. Now D.decodeQueueSize is 0.
T) `D.decode()` for sample mozilla#7 succeeded. Get VideoFrame mozilla#7.
T) Get a dequeue event mozilla#8. D.decodeQueueSize is still 0.
   => "Dequeue event after queue empty" fails here
   => "Dequeue event without decreased queue size" fails here as well

In brief, what VideoDecoder can guarantee are the order of dequeue
event, decode() result, and the flush() result:

1. For sample #N, its dequeue event arrives before it's decode()
   callback
2. The results/callbacks of decode() and flush() are arrived in FIFO
   order

There is no guarantee that `decodeQueueSize` read on the VideoDecoder's
owner thread only decrease one per dequeue event. If the
codec-work-queue decodes sample #1, mozilla#2, ... , #K while the dequeue event
for sample #1 is being dispatched to or handled on the VideoDecoder's
owner thread, the last-dequeueQueueSize can drop more than one compared
to it's previous value, and for the same reason, the dequeue event can
arrive even if the last-dequeueQueueSize has been set to 0.

Differential Revision: https://phabricator.services.mozilla.com/D179514
ChunMinChang added a commit to ChunMinChang/gecko-dev that referenced this pull request Jun 5, 2023
```js
let lastDequeueSize = Infinity;
decoder.ondequeue = () => {
  assert_greater_than(lastDequeueSize, 0, "Dequeue event after queue empty");
  assert_greater_than(lastDequeueSize, decoder.decodeQueueSize,
                      "Dequeue event without decreased queue size");
  lastDequeueSize = decoder.decodeQueueSize;
};
```

The above checkes doesn't really work since the VideoDecoder's
codec-work-queue runs in parallel with the VideoDecoder interface. The
dequeue events can arrive after the last dequeue size has been 0 if the
work queue decodes multiple samples while VideoDecoder is processing
just one dequeue event. Besides, `decodeQueueSize` can change between
the two `decoder.decodeQueueSize` calls since it can be mutated on both
VideoDecoder's owner thread and the codec-work-queue thread. As a
result, these two `decodeQueueSize` can be different, and the
`lastDequeueSize` is not guaranteed to be decreased one at a time per
event, even if the internal decodeQueueSize is decreased one at a time
(on codec-work-queue thread). The value can be decreased more than one
at a time.

The following example demonstrates one case when those checks can fail.

Suppose VideoDecoder *D* runs on thread *T* (main or worker) and
codec-work-queue runs on thread *Q*. In the test, by the time
VideoDecoder is `configure`d successfully and `decode` request are sent,
the codec-work-queue is ready to `decode` the pending samples. Below
illustrates why the wpt checks in the begining don't work

Q) The underlying codec is configured, ready to decode sample #1.
   Schedule a dequeue event. The current queue size is 9.
T) Get a dequeue event #1. Now D.decodeQueueSize is 9.
Q) Decode sample #1 succeeded, ready to decode sample mozilla#2. Schedule a
   dequeue event. The current queue size is 8.
T) `D.decode()` for sample #1 succeeded. Get VideoFrame #1.
T) Get a dequeue event mozilla#2. Now D.decodeQueueSize is 8.
Q) Decode sample mozilla#2 succeeded, ready to decode sample mozilla#3. Schedule a
   dequeue event. The current queue size is 7.
T) `D.decode()` for sample mozilla#2 succeeded. Get VideoFrame mozilla#2.
Q) Decode sample mozilla#3 succeeded, ready to decode sample mozilla#4. Schedule a
   dequeue event. The current queue size is 6.
Q) Decode sample mozilla#4 succeeded, ready to decode sample mozilla#5. Schedule a
   dequeue event. The current queue size is 5.
T) Get a dequeue event mozilla#3. Now D.decodeQueueSize is 5.
T) `D.decode()` for sample mozilla#3 succeeded. Get VideoFrame mozilla#3.
T) Get a dequeue event mozilla#4. Now D.decodeQueueSize is 5.
   => "Dequeue event without decreased queue size" fails here
Q) Decode sample mozilla#5 succeeded, ready to decode sample mozilla#6. Schedule a
   dequeue event. The current queue size is 4.
Q) Decode sample mozilla#6 succeeded, ready to decode sample mozilla#7. Schedule a
   dequeue event. The current queue size is 3.
Q) Decode sample mozilla#7 succeeded, ready to decode sample mozilla#8. Schedule a
   dequeue event. The current queue size is 2.
T) `D.decode()` for sample mozilla#4 succeeded. Get VideoFrame mozilla#4.
T) Get a dequeue event mozilla#5. Now D.decodeQueueSize is 2.
T) `D.decode()` for sample mozilla#5 succeeded. Get VideoFrame mozilla#5.
T) Get a dequeue event mozilla#6. Now D.decodeQueueSize is 2.
   => "Dequeue event without decreased queue size" fails again here
Q) Decode sample mozilla#8 succeeded, ready to decode sample mozilla#9. Schedule a
   dequeue event. The current queue size is 1.
T) `D.decode()` for sample mozilla#6 succeeded. Get VideoFrame mozilla#6.
Q) Decode sample mozilla#9 succeeded, ready to decode sample mozilla#10. Schedule a
   dequeue event. The current queue size is 0.
T) Get a dequeue event mozilla#7. Now D.decodeQueueSize is 0.
T) `D.decode()` for sample mozilla#7 succeeded. Get VideoFrame mozilla#7.
T) Get a dequeue event mozilla#8. D.decodeQueueSize is still 0.
   => "Dequeue event after queue empty" fails here
   => "Dequeue event without decreased queue size" fails here as well

In brief, what VideoDecoder can guarantee are the order of dequeue
event, decode() result, and the flush() result:

1. For sample #N, its dequeue event arrives before it's decode()
   callback
2. The results/callbacks of decode() and flush() are arrived in FIFO
   order

There is no guarantee that `decodeQueueSize` read on the VideoDecoder's
owner thread only decrease one per dequeue event. If the
codec-work-queue decodes sample #1, mozilla#2, ... , #K while the dequeue event
for sample #1 is being dispatched to or handled on the VideoDecoder's
owner thread, the last-dequeueQueueSize can drop more than one compared
to it's previous value, and for the same reason, the dequeue event can
arrive even if the last-dequeueQueueSize has been set to 0.

Differential Revision: https://phabricator.services.mozilla.com/D179514

Depends on D177212
moz-v2v-gh pushed a commit that referenced this pull request Jun 22, 2023
…operty invalidation", a=testonly

Automatic update from web-platform-tests
Revert "[A11y] Reland targeted cached property invalidation"

This reverts commit 3438f2a59daa31ad1d86777d73e1cff836cef570.

Reason for revert: Suspect causing blink_wpt_tests and blink_web_tests failure on Linux Tests (dbg)(1) bot.

Failed tests:
blink_wpt_tests failed because of:
external/wpt/css/css-contain/content-visibility/detach-locked-slot-children-crash.html
external/wpt/css/css-contain/content-visibility/element-reassigned-to-skipped-slot.html
external/wpt/css/css-contain/content-visibility/element-reassigned-to-slot-in-skipped-subtree.html
external/wpt/html/semantics/forms/the-input-element/focus-dynamic-type-change-on-blur.html
...7 more failure(s) (11 total)...

blink_web_tests failed because of:
accessibility/details-summary-crash.html
fast/events/drag-on-removed-slider-does-not-crash.html
fast/forms/range/range-type-change-onchange-2.html
html/details_summary/details-add-summary.html
...5 more failure(s) (9 total)...

First build failure:
https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20Tests%20(dbg)(1)/114032/overview

Sample log:
---
STDERR: #6 0x7fc01bd0361d logging::CheckError::~CheckError()
STDERR: #7 0x7fbffd21d08a blink::FlatTreeTraversal::AssertPrecondition()
STDERR: #8 0x7fbffd21cfd5 blink::FlatTreeTraversal::Parent()
STDERR: #9 0x7fbffd3c2a45 blink::FlatTreeTraversal::AncestorsOf()
STDERR: #10 0x7fbffd3d410e blink::(anonymous namespace)::NearestLockedExclusiveAncestor()
STDERR: #11 0x7fbffd3d3d17 blink::DisplayLockUtilities::IsInUnlockedOrActivatableSubtree()
STDERR: #12 0x7fbfedfabc4b blink::DisplayLockUtilities::ShouldIgnoreNodeDueToDisplayLock()
STDERR: #13 0x7fbfedf8b61c blink::AXObject::ToString()
STDERR: #14 0x7fbfedf8eccc blink::AXObject::Detach()
STDERR: #15 0x7fbfedf512df blink::AXNodeObject::Detach()
STDERR: #16 0x7fbfedf2d6a5 blink::AXLayoutObject::Detach()
STDERR: #17 0x7fbfedfce51a blink::AXObjectCacheImpl::Remove()
STDERR: #18 0x7fbfedfcd998 blink::AXObjectCacheImpl::Remove()
STDERR: #19 0x7fbfedfcdd74 blink::AXObjectCacheImpl::Remove()
STDERR: #20 0x7fbfedfce992 blink::AXObjectCacheImpl::Remove()
STDERR: #21 0x7fbffe6d16be blink::LayoutObject::WillBeDestroyed()
---

Original change's description:
> [A11y] Reland targeted cached property invalidation
>
> Relands the following CLS:
> * Enhance performance by targeting value updates to specific nodes, commit 704633e6846e44b20c488a3eb98fa43c2c8e4591.
> * Don't queue anything for irrelevant attribute changes, commit 2c66a62ed62e601b7a81271e4be4f9e173ce9afc.
> * Add comment explaining call to UpdateStyleAndLayoutTreeForNode(), commit 73b9eed3b48bc8ce70de657672755f44a89e7358.
> * Ensure cached values not invalidated during the computation of them, commit 4d167a62cd13d5209ecefb664e3690ac955bc559.
> * Run a test with --force-renderer-accessibility that used to fail, commit cab7ecd829b24acf677e02f8f118085eaad7f799.
> * Simplify code to update cached focusable state, commit 79cb184e5dab5f6084ec78d485bd9496eaa0aaf8.
> * Simplify code that invalidates cached values on an AXObject, commit 6df79a50a55fe5cf99d2c50f7308e1236361b771.
>
> Fixed: 1446864, 1446550, 1434555, 1362758
> Change-Id: I16855bdcb746cb41387b69e1e97ab72ffc47e342
> Cq-Do-Not-Cancel-Tryjobs: true
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4545510
> Commit-Queue: Aaron Leventhal <aleventhal@chromium.org>
> Reviewed-by: Jacques Newman <janewman@microsoft.com>
> Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
> Reviewed-by: Philip Rogers <pdr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1157878}

Change-Id: Iefe59fe1933747346eda8827fd683f310d6cddb3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4615927
Reviewed-by: Takuto Ikuta <tikuta@chromium.org>
Owners-Override: Takuto Ikuta <tikuta@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Auto-Submit: Takashi Sakamoto <tasak@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1157993}

--

wpt-commits: b2f88bfbff5f2806344bb479e7382a3618197e05
wpt-pr: 40564
cfallin added a commit to cfallin/gecko-dev that referenced this pull request Aug 23, 2023
moz-v2v-gh pushed a commit that referenced this pull request Nov 16, 2023
…chevobbe

Just starting up a debug build you will get 40 copies of this printed.

The uri that we fail to get host of is about:newtab. One stack looks like this

#2: mozilla::BasePrincipal::GetIsLoopbackHost(bool*)
#3: mozilla::net::LoadInfo::LoadInfo(nsIPrincipal*, nsIPrincipal*, nsINode*, unsigned int, nsIContentPolicy::nsContentPolicyType, mozilla::Maybe<mozilla::dom::ClientInfo> const&, mozilla::Maybe<mozilla::dom::ServiceWorkerDescriptor> const&, unsigned int, bool
#4: ShouldLoadCachedImage(imgRequest*, mozilla::dom::Document*, nsIPrincipal*, nsIContentPolicy::nsContentPolicyType, bool)
#5: imgLoader::LoadImage(nsIURI*, nsIURI*, nsIReferrerInfo*, nsIPrincipal*, unsigned long long, nsILoadGroup*, imgINotificationObserver*, nsINode*, mozilla::dom::Document*, unsigned int, nsISupports*, nsIContentPolicy::nsContentPolicyType, nsTSubstring<char16
#6: nsContentUtils::LoadImage(nsIURI*, nsINode*, mozilla::dom::Document*, nsIPrincipal*, unsigned long long, nsIReferrerInfo*, imgINotificationObserver*, int, nsTSubstring<char16_t> const&, imgRequestProxy**, nsIContentPolicy::nsContentPolicyType, bool, bool,
#7: mozilla::css::ImageLoader::LoadImage(mozilla::StyleComputedUrl const&, mozilla::dom::Document&)
#8: mozilla::StyleComputedUrl::ResolveImage(mozilla::dom::Document&, mozilla::StyleComputedUrl const*)
#9: nsStyleImageLayers::ResolveImages(mozilla::dom::Document&, nsStyleImageLayers const*)
#10: mozilla::ComputedStyle::StartImageLoads(mozilla::dom::Document&, mozilla::ComputedStyle const*)

Differential Revision: https://phabricator.services.mozilla.com/D193349
moz-v2v-gh pushed a commit that referenced this pull request Dec 20, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/a93f581705787105ac28bccdc179778fd4400298
    dcsctp: Don't generate FORWARD-TSN across stream resets

    This was a fun bug which proved to be challenging to find a good
    solution for. The issue comes from the combination of partial
    reliability and stream resetting, which are covered in different RFCs,
    and where they don't refer to each other...

    Stream resetting (RFC 6525) is used in WebRTC for closing a Data
    Channel, and is done by signaling to the receiver that the stream
    sequence number (SSN) should be set to zero (0) at some time. Partial
    reliability (RFC 3758) - and expiring messages that will not be
    retransmitted - is done by signaling that the SSN should be set to a
    certain value at a certain TSN, as the messages up until the provided
    SSN are not to be expected to be sent again.

    As these two functionalities both work by signaling to the receiver
    what the next expected SSN should be, they need to do it correctly not
    to overwrite each others' intent. And here was the bug. An example
    scenario where this caused issues, where we are Z (the receiver),
    getting packets from the sender (A):

     5  A->Z          DATA (TSN=30, B, SID=2, SSN=0)
     6          Z->A  SACK (Ack=30)
     7  A->Z          DATA (TSN=31, E, SID=2, SSN=0)
     8  A->Z          RE_CONFIG (REQ=30, TSN=31, SID=2)
     9          Z->A  RE_CONFIG (RESP=30, Performed)
    10          Z->A  SACK (Ack=31)
    11  A->Z          DATA (TSN=32, SID=1)
    12  A->Z          FORWARD_TSN (TSN=32, SID=2, SSN=0)

    Let's assume that the path Z->A had packet loss and A never really
    received our responses (#6, #9, #10) in time.

    At #5, Z receives a DATA fragment, which it acks, and at #7 the end of
    that message. The stream is then reset (#8) which it signals that it
    was performed (#9) and acked (#10), and data on another stream (2) was
    received (#11). Since A hasn't received any ACKS yet, and those chunks
    on SID=2 all expired, A sends a FORWARD-TSN saying that "Skip to TSN=32,
    and don't expect SID=2, SSN=0". That makes the receiver expect the SSN
    on SID=2 to be SSN=1 next time at TSN=32.

    But that's not good at all - A reset the stream at #8 and will want to
    send the next message on SID=2 using SSN=0 - not 1. The FORWARD-TSN
    clearly can't have a TSN that is beyond the stream reset TSN for that
    stream.

    This is just one example - combining stream resetting and partial
    reliability, together with a lossy network, and different variants of
    this can occur, which results in the receiver possibly not delivering
    packets because it expects a different SSN than the one the sender is
    later using.

    So this CL adds "breakpoints" to how far a FORWARD-TSN can stretch. It
    will simply not cross any Stream Reset last assigned TSNs, and only when
    a receiver has acked that all TSNs up till the Stream Reset last
    assigned TSN has been received, it will proceed expiring chunks after
    that.

    Bug: webrtc:14600
    Change-Id: Ibae8c9308f5dfe8d734377d42cce653e69e95731
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321600
    Commit-Queue: Victor Boivie <boivie@webrtc.org>
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Cr-Commit-Position: refs/heads/main@{#40829}
moz-v2v-gh pushed a commit that referenced this pull request Jan 23, 2024
…ect> / <embed> as subdocuments. r=longsonr

These look like two really old bugs.

Part of the issue is that <object> / <embed> manage their frame loader quite
differently from <iframe>. This means that we may have a PresShell /
ViewManager / etc for a frame loader that doesn't yet have a frame associated.

For example, this is the viewport creation for the SVG document that reproduces
the problem:

	#0  0x00005cc60e8302e7 in mozilla::ViewportFrame::SetViewInternal(nsView*) (this=0x68599020, aView=0x683d8f00) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/ViewportFrame.h:106
	#1  0x00005cc60e842858 in nsIFrame::SetView(nsView*) (this=0x68599020, aView=0x683d8f00) at /home/emilio/src/moz/gecko/layout/generic/nsFrame.cpp:7057
	#2  0x00005cc60e77258a in nsCSSFrameConstructor::ConstructRootFrame() (this=0xc72c715e00) at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:2424
	#3  0x00005cc60e7342f5 in mozilla::PresShell::Initialize() (this=0x6830e000) at /home/emilio/src/moz/gecko/layout/base/PresShell.cpp:1758
	#4  0x00005cc60c9fb02a in nsContentSink::StartLayout(bool) (this=<optimized out>, aIgnorePendingSheets=<optimized out>) at /home/emilio/src/moz/gecko/dom/base/nsContentSink.cpp:1160
	#5  0x00005cc60e2c1581 in nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int, bool)
	    (this=<optimized out>, aName=<optimized out>, aAtts=0x6fde8200, aAttsCount=<optimized out>, aLineNumber=3, aColumnNumber=<optimized out>, aInterruptable=true) at /home/emilio/src/moz/gecko/dom/xml/nsXMLContentSink.cpp:982
	#6  0x00005cc60e2c17d7 in non-virtual thunk to nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int) () at /home/emilio/src/moz/gecko/dom/xml/nsXMLContentSink.cpp:889
	#7  0x00005cc60c360307 in nsExpatDriver::HandleStartElement(void*, char16_t const*, char16_t const**) (aUserData=0x224f650d0cc0, aName=0x685aef20 u"http://www.w3.org/2000/svg\xffffdesc", aAtts=0x6fde8200)
	    at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:293
	#8  0x00005cc60ee91cea in doContent (parser=0xc72c70f800, startTagLevel=0, enc=<optimized out>, s=<optimized out>, end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, nextPtr=0x7ffca2653288, haveMore=1 '\001')
	    at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:2872
	#9  0x00005cc60ee90059 in contentProcessor (parser=0xc72c70f800, start=0xffffffe6 <error: Cannot access memory at address 0xffffffe6>, end=0xc72c511360 "", endPtr=0x1) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:2528
	#10 0x00005cc60ee8f8d5 in doProlog
	    (parser=<optimized out>, enc=0x5cc612ce0930 <little2_encoding_ns>, s=0x5bbd31ab508e "<", end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, tok=<optimized out>, next=<optimized out>, nextPtr=0x7ffca2653288, haveMore=1 '\001', allowClosingDoctype=1 '\001') at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:4591
	#11 0x00005cc60ee8d86e in prologProcessor (parser=0xc72c70f800, s=0x5bbd31ab5020 "<", end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, nextPtr=0x7ffca2653288) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:4311
	#12 0x00005cc60ee8cf45 in MOZ_XML_Parse (parser=0xc72c70f800, s=0x5bbd31ab5020 "<", len=262144, isFinal=0) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:1894
	#13 0x00005cc60c3627bc in nsExpatDriver::ParseBuffer(char16_t const*, unsigned int, bool, unsigned int*)
	    (this=0x224f650d0cc0, aBuffer=0x5bbd31ab5020 u"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<svg height=\"2970\" width=\"2100\" viewBox=\"0 0 2100 2970\" version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlin"..., aLength=131072, aIsFinal=false, aConsumed=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:875
	#14 0x00005cc60c362c91 in nsExpatDriver::ConsumeToken(nsScanner&, bool&) (this=<optimized out>, aScanner=..., aFlushTokens=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:970
	#15 0x00005cc60c3666a8 in nsParser::Tokenize(bool) (this=0x224f65038e80, aIsFinalChunk=false) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:1410
	#16 0x00005cc60c36595e in nsParser::ResumeParse(bool, bool, bool) (this=0x224f65038e80, allowIteration=true, aIsFinalChunk=false, aCanInterrupt=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:961
	#17 0x00005cc60c366c86 in nsParser::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (this=0x224f65038e80, request=<optimized out>, pIStream=0x6fdfc430, sourceOffset=<optimized out>, aLength=131072)
	    at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:1317
	#18 0x00005cc60c897cc2 in nsObjectLoadingContent::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (this=<optimized out>, aRequest=0x68483080, aInputStream=0x6fdfc430, aOffset=0, aCount=131072)
	    at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:1055
	#19 0x00005cc60b9d18f8 in mozilla::net::HttpChannelChild::DoOnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long, unsigned int)
	    (this=0x68483000, aRequest=0x68483080, aContext=<optimized out>, aStream=0x6fdfc430, aOffset=0, aCount=743510880) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:968
	#20 0x00005cc60b9d5cbf in mozilla::net::HttpChannelChild::OnTransportAndData(nsresult const&, nsresult const&, unsigned long const&, unsigned int const&, nsTString<char> const&)
	    (this=0x68483000, aChannelStatus=<optimized out>, aTransportStatus=@0x683be5bc: -2142568440, aOffset=<optimized out>, aCount=<optimized out>, aData=...) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:867
	#21 0x00005cc60badb535 in mozilla::net::ChannelEventQueue::FlushQueue() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/netwerk/ipc/ChannelEventQueue.cpp:90
	#22 0x00005cc60b976fda in mozilla::net::ChannelEventQueue::MaybeFlushQueue() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/net/ChannelEventQueue.h:350
	#23 0x00005cc60baec442 in mozilla::net::ChannelEventQueue::CompleteResume() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/net/ChannelEventQueue.h:329
	#24 mozilla::net::ChannelEventQueue::ResumeInternal()::CompleteResumeRunnable::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/ipc/ChannelEventQueue.cpp:148
	#25 0x00005cc60b53d4f1 in mozilla::SchedulerGroup::Runnable::Run() (this=0x685b0200) at /home/emilio/src/moz/gecko/xpcom/threads/SchedulerGroup.cpp:282
	#26 0x00005cc60b54ff80 in nsThread::ProcessNextEvent(bool, bool*) (this=0x3dd7f4f3020, aMayWait=<optimized out>, aResult=0x7ffca2653ea7) at /home/emilio/src/moz/gecko/xpcom/threads/nsThread.cpp:1220
	#27 0x00005cc60b552f0d in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x68599020, aMayWait=true) at /home/emilio/src/moz/gecko/xpcom/threads/nsThreadUtils.cpp:481

The parent view may not be set properly if the frame is not current by the time
it is created. For example in this case the parent for the root view is
non-null and comes from the following MakeWindow call:

	#0  nsDocumentViewer::MakeWindow(nsSize const&, nsView*) (this=0xc72ca72cd0, aSize=..., aContainerView=0x683ba500) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:2368
	#1  0x00005cc60e789b50 in nsDocumentViewer::InitInternal(nsIWidget*, nsISupports*, mozilla::dom::WindowGlobalChild*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, bool, bool, bool)
	    (this=0xc72ca72cd0, aParentWidget=<optimized out>, aState=0x0, aActor=0x0, aBounds=..., aDoCreation=true, aNeedMakeCX=<optimized out>, aForceSetNewDocument=<optimized out>)
	    at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:933
	#2  0x00005cc60e789959 in nsDocumentViewer::Init(nsIWidget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::dom::WindowGlobalChild*)
	    (this=0xc72ca72cd0, aParentWidget=0x7ffca2651020, aBounds=..., aActor=0x7f6216725c00) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:762
	#3  0x00005cc60f4f584f in nsDocShell::SetupNewViewer(nsIContentViewer*, mozilla::dom::WindowGlobalChild*) (this=0x684db000, aNewViewer=<optimized out>, aWindowActor=<optimized out>)
	    at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:8017
	#4  0x00005cc60f4f5204 in nsDocShell::Embed(nsIContentViewer*, mozilla::dom::WindowGlobalChild*) (this=0x684db000, aContentViewer=0x7ffca2651020, aWindowActor=0x683ba500) at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:5745
	#5  0x00005cc60f4dbc7b in nsDocShell::CreateContentViewer(nsTSubstring<char> const&, nsIRequest*, nsIStreamListener**) (this=0x684db000, aContentType=..., aRequest=0x68483080, aContentHandler=<optimized out>)
	    at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:7819
	#6  0x00005cc60f4dab99 in nsDSURIContentListener::DoContent(nsTSubstring<char> const&, bool, nsIRequest*, nsIStreamListener**, bool*)
	    (this=0x683056a0, aContentType=..., aIsContentPreferred=<optimized out>, aRequest=0x68483080, aContentHandler=0xc72c5e8608, aAbortProcess=0x7ffca265139f) at /home/emilio/src/moz/gecko/docshell/base/nsDSURIContentListener.cpp:181
	#7  0x00005cc60c2fd8f5 in nsDocumentOpenInfo::TryContentListener(nsIURIContentListener*, nsIChannel*) (this=0xc72c5e85e0, aListener=0x683056a0, aChannel=<optimized out>) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:632
	#8  0x00005cc60c2fccd1 in nsDocumentOpenInfo::DispatchContent(nsIRequest*, nsISupports*) (this=0xc72c5e85e0, request=0x68483080, aCtxt=<optimized out>) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:313
	#9  0x00005cc60c2fc5aa in nsDocumentOpenInfo::OnStartRequest(nsIRequest*) (this=<optimized out>, request=0x68483080) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:191
	#10 0x00005cc60c8975c4 in nsObjectLoadingContent::LoadObject(bool, bool, nsIRequest*) (this=0x4b1b3938b6a8, aNotify=<optimized out>, aForceLoad=<optimized out>, aLoadingChannel=0x68483080)
	    at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:2218
	#11 0x00005cc60c89681f in nsObjectLoadingContent::OnStartRequest(nsIRequest*) (this=0x4b1b3938b6a8, aRequest=0x68483080) at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:1006
	#12 0x00005cc60b9d1020 in mozilla::net::HttpChannelChild::DoOnStartRequest(nsIRequest*, nsISupports*) (this=0x68483000, aRequest=0x68483080, aContext=<optimized out>)
	    at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:708
	#13 0x00005cc60b9d481b in mozilla::net::HttpChannelChild::OnStartRequest(nsresult const&, mozilla::net::nsHttpResponseHead const&, bool const&, mozilla::net::nsHttpHeaderArray const&, mozilla::net::ParentLoadInfoForwarderArgs const&, bool const&, bool const&, bool const&, unsigned long const&, int const&, unsigned int const&, nsTString<char> const&, nsTString<char> const&, mozilla::net::NetAddr const&, mozilla::net::NetAddr const&, unsigned int const&, nsTString<char> const&, long const&, bool const&, bool const&, bool const&, mozilla::net::ResourceTimingStructArgs const&, bool const&, mozilla::Maybe<unsigned int> const&, bool const&, nsILoadInfo::CrossOriginOpenerPolicy const&)

However, even though aContainerView is non-null, the view is incorrect, it's
the view for the _old_ frame.

The view parent/child relationship gets cleared properly in:

	#1  0x00005cc60e8e82bf in BeginSwapDocShellsForViews (aSibling=0x0) at /home/emilio/src/moz/gecko/layout/generic/nsSubDocumentFrame.cpp:1027
	warning: Source file is more recent than executable.
	#2  0x00005cc60e8e810b in nsSubDocumentFrame::DestroyFrom (this=0x6cd04eaa45a8, aDestructRoot=0x6cd04eaa45a8, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsSubDocumentFrame.cpp:943
	#3  0x00005cc60e7b71a3 in nsIFrame::Destroy (this=0x6cd04eaa45a8) at /home/emilio/src/moz/gecko/layout/generic/nsIFrame.h:657
	#4  0x00005cc60e80baac in nsBlockFrame::RemoveFrame (this=0x4b1b39362d88, aListID=<optimized out>, aOldFrame=0x6cd04eaa45a8) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:5597
	#5  0x00005cc60e8df29f in nsPlaceholderFrame::DestroyFrom (this=0x4b1b39363240, aDestructRoot=0x4b1b39363240, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsPlaceholderFrame.cpp:181
	#6  0x00005cc60e80cf19 in nsBlockFrame::DoRemoveFrameInternal (this=<optimized out>, aDeletedFrame=0x0, aFlags=<optimized out>, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:6265
	#7  0x00005cc60e82d947 in nsBlockFrame::DoRemoveFrame (this=0x4b1b39362d88, aDeletedFrame=0x683d8f00, aFlags=244338087) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.h:528
	#8  0x00005cc60e80ba3a in nsBlockFrame::RemoveFrame (this=0x4b1b39362d88, aListID=<optimized out>, aOldFrame=0x4b1b39363240) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:5581
	#9  0x00005cc60e77fd5c in nsCSSFrameConstructor::ContentRemoved (this=<optimized out>, aChild=0x4b1b3938b600, aOldNextSibling=<optimized out>, aFlags=<optimized out>)
	    at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:7583
	#10 0x00005cc60e779a35 in nsCSSFrameConstructor::RecreateFramesForContent (this=0x6fdf9800, aContent=0x4b1b3938b600, aInsertionKind=nsCSSFrameConstructor::InsertionKind::Sync)
	    at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:8593
	#11 0x00005cc60e751745 in mozilla::RestyleManager::ProcessRestyledFrames (this=<optimized out>, aChangeList=...) at /home/emilio/src/moz/gecko/layout/base/RestyleManager.cpp:1484

But the temporary state is stored in the _old_ frame-loader, so when we create
the new frame, we get to nsSubDocumentFrame::Init, and find nothing, and thus
go through nsFrameLoader::Show. But we do have a pres-shell, and
nsFrameLoader::Show just early-returns then, and thus we end up with a detached
pres shell which is not hooked to the view tree and thus not painted...

So there are multiple potential fixes. First (this is the approach this patch
takes):

 * Make nsHideViewer not fail to hide a presentation when the frame loader
   has changed. This is not an issue per se, but leaves stale views / etc
   living for too long which is not nice.

 * Fix up the Show() code path to handle this case properly by parenting the
   pres-shell and initializing the docshell properly.

Second potential fix would be to store the temporary state somewhere else than
the frame loader (like the element). This may be a less invasive change
somehow, but it looks pretty fishy to me, and not particularly better...

Terribly sorry about the lack of test-case, but this is racy as crazy and I had
a lot of trouble to even reproduce it in a debug build. This needs the
PresShell creation for the subdocument to happen right after setting .data on
the <object>, but before processing its reframe.

Differential Revision: https://phabricator.services.mozilla.com/D69487
moz-v2v-gh pushed a commit that referenced this pull request Jun 20, 2024
…lone. r=rhunt.

The #9 patch removed all wasm-specific fields from wasm::Metadata, but did
not remove wasm::Metadata itself, because it is inherited from by
AsmJSMetadata, and used to provide different behaviour for wasm vs asm.js in a
few obscure cases related to the profiler.

This patch restricts wasm::Metadata to be an abstract class that provides
access to (is the pure virtual base class of) AsmJSMetadata.  wasm::Metadata is
removed from WasmCode.h and instead reappears in AsmJS.h in pure virtual form.
Any place that previously took a Metadata& now takes takes a Metadata*, and
that is non-null only in the case when we are compiling asm.js.

The effect is to restrict wasm::Metadata and js::AsmJSMetadata to providing
support for asm.js compilation only.  The next patch in the series (#11)
completes the transformation by renaming those two types appropriately.

Differential Revision: https://phabricator.services.mozilla.com/D211165
moz-v2v-gh pushed a commit that referenced this pull request Jun 21, 2024
…lone. r=rhunt.

The #9 patch removed all wasm-specific fields from wasm::Metadata, but did
not remove wasm::Metadata itself, because it is inherited from by
AsmJSMetadata, and used to provide different behaviour for wasm vs asm.js in a
few obscure cases related to the profiler.

This patch restricts wasm::Metadata to be an abstract class that provides
access to (is the pure virtual base class of) AsmJSMetadata.  wasm::Metadata is
removed from WasmCode.h and instead reappears in AsmJS.h in pure virtual form.
Any place that previously took a Metadata& now takes takes a Metadata*, and
that is non-null only in the case when we are compiling asm.js.

The effect is to restrict wasm::Metadata and js::AsmJSMetadata to providing
support for asm.js compilation only.  The next patch in the series (#11)
completes the transformation by renaming those two types appropriately.

Differential Revision: https://phabricator.services.mozilla.com/D211165
moz-v2v-gh pushed a commit that referenced this pull request Aug 8, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/876d0c9881eab8e7f8389812eb3738bdd374aa22
    Fix use-of-uninitialized-value in NetEq tests.

    The new version of MSan (rolled by [1]) detects the following:

    ```
    ==39908==WARNING: MemorySanitizer: use-of-uninitialized-value
        #0 0x5591400a52ef in GetPlayoutDelayMs ./../../modules/audio_coding/neteq/decision_logic.cc:466:35
        #1 0x5591400a52ef in webrtc::DecisionLogic::ExpectedPacketAvailable(webrtc::NetEqController::NetEqStatus) ./../../modules/audio_coding/neteq/decision_logic.cc:311:36
        #2 0x5591400a39e9 in webrtc::DecisionLogic::GetDecision(webrtc::NetEqController::NetEqStatus const&, bool*) ./../../modules/audio_coding/neteq/decision_logic.cc:0:0
        #3 0x55913cf590c9 in webrtc::DecisionLogicTest_PreemptiveExpand_Test::TestBody() ./../../modules/audio_coding/neteq/decision_logic_unittest.cc:139:3
        #4 0x55913ef28283 in HandleExceptionsInMethodIfSupported<testing::Test, void> ./../../third_party/googletest/src/googletest/src/gtest.cc:0:3
        #5 0x55913ef28283 in testing::Test::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:2710:5
        #6 0x55913ef2ab46 in testing::TestInfo::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:2856:11
        #7 0x55913ef2da34 in testing::TestSuite::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:3034:30
        #8 0x55913ef621e8 in testing::internal::UnitTestImpl::RunAllTests() ./../../third_party/googletest/src/googletest/src/gtest.cc:5964:44
        #9 0x55913ef60f54 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> ./../../third_party/googletest/src/googletest/src/gtest.cc:0:0
        #10 0x55913ef60f54 in testing::UnitTest::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:5543:10
        #11 0x55913ee1a944 in RUN_ALL_TESTS ./../../third_party/googletest/src/googletest/include/gtest/gtest.h:2334:73
        #12 0x55913ee1a944 in webrtc::(anonymous namespace)::TestMainImpl::Run(int, char**) ./../../test/test_main_lib.cc:203:21
        #13 0x55913cbd36b8 in main ./../../test/test_main.cc:72:16
        #14 0x7fdb18c73082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16
        #15 0x55913cb3e1a9 in _start ??:0:0
    ```

    [1] - https://webrtc-review.googlesource.com/c/src/+/353620

    Bug: b/344970813
    Change-Id: I9b5d7791e68b4c494168ba9f007a3099ae21fed4
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/353581
    Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
    Reviewed-by: Jakob Ivarsson‎ <jakobi@webrtc.org>
    Commit-Queue: Jakob Ivarsson‎ <jakobi@webrtc.org>
    Cr-Commit-Position: refs/heads/main@{#42433}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants