Bug 964545 Add-on SDK page-mods are now debuggable #5

erikvold · 2014-01-28T07:24:55Z

No description provided.

Gozala · 2014-01-29T20:54:55Z

toolkit/devtools/DevToolsExtensions.jsm

+
+// when the window is destroyed, eliminate the associated globals cache
+
+Services.obs.addObserver(function observer(subject, topic, data) {


I would suggest use use of weak maps + Cu.nondeterministicGetWeakMapKeys() to avoid tracking windows etc. Plus global already has a reference to a window it's attached to.

Another option would be to use "weak sets" similar to how we did them here:
https://github.com/mozilla/addon-sdk/blob/master/lib/sdk/lang/weak-set.js

update nemo rpm packaging

Making directories

Bug 1087456

… fires, causing orange. r=orange Example stack, from editor/libeditor/tests/browserscope/test_richtext2.html : ###!!! ASSERTION: should only call on first continuation/ib-sibling: 'nsLayoutUtils::IsFirstContinuationOrIBSplitSibling(this)', file /builds/slave/m-in-l64-d-0000000000000000000/build/src/layout/base/../generic/nsIFrame.h, line 875 #01: AdjustAppendParentForAfterContent [layout/base/nsCSSFrameConstructor.cpp:6059] #2: nsCSSFrameConstructor::ContentAppended(nsIContent*, nsIContent*, bool) [layout/base/nsCSSFrameConstructor.cpp:7155] #3: PresShell::ContentAppended(nsIDocument*, nsIContent*, nsIContent*, int) [layout/base/nsPresShell.cpp:4520] #4: nsNodeUtils::ContentAppended(nsIContent*, nsIContent*, int) [dom/base/nsNodeUtils.cpp:132] #5: nsINode::doInsertChildAt(nsIContent*, unsigned int, bool, nsAttrAndChildArray&) [dom/base/nsINode.cpp:1544] #6: nsINode::ReplaceOrInsertBefore(bool, nsINode*, nsINode*, mozilla::ErrorResult&) [dom/base/nsINode.cpp:2209] #7: mozilla::dom::NodeBinding::appendChild [obj-firefox/dom/bindings/NodeBinding.cpp:600]

Unidisk gecko

Bug 1197751 - Add event shutter of RemoteControlService; a=jocheng

…instead of ignoring them. r=Gijs r=dao CMD + a number key is a keyboard shortcut to select that tab number. (CMD+9 will always select the right-most tab, regardless of the tab count.) Currently, if the number is greater than the tab count, then the keyboard shortcut is ignored. With this patch, the right-most tab will be selected instead. For example, if there are five tabs and the user accidentally enters CMD+6 instead of CMD+5, selecting tab #5 is probably what they wanted instead of ignoring the keyboard shortcut. Also expand the tab selection tests to cover more edge cases.

…instead of ignoring them. r=Gijs r=dao CMD + a number key is a keyboard shortcut to select that tab number. (CMD+9 will always select the right-most tab, regardless of the tab count.) Currently, if the number is greater than the tab count, then the keyboard shortcut is ignored. With this patch, the right-most tab will be selected instead. For example, if there are five tabs and the user accidentally enters CMD+6 instead of CMD+5, selecting tab mozilla#5 is probably what they wanted instead of ignoring the keyboard shortcut. Also expand the tab selection tests to cover more edge cases.

getElementRect should return floats not integers so updating to act that... Source-Repo: https://github.com/mozilla/geckodriver Source-Revision: 353af14d2eabccc5f3dcfb96c0cad372b49e0581 --HG-- extra : rebase_source : b1fed7c792adeb5ba9f32e3afdc591f530e6c9b0

getElementRect should return floats not integers so updating to act that... Source-Repo: https://github.com/mozilla/geckodriver Source-Revision: 353af14d2eabccc5f3dcfb96c0cad372b49e0581

… collapsed to the end of composition r=m_kato When you start new composition during converting with Mozc in e10s mode, the following things occur: 1. Mozc commits previous composition. 2. Gecko dispatches eCompositionCommit event. 3. Mozc sets new composition string (skipping composition start signal). 4. Gecko dispatches eCompositionStart and eCompositionChange event. 5. Selection is changed asynchronously. 6. Gecko sets position of IME windows. At #4, Gecko stores start of composition as selection start, then, trying to adjust it at #5. However, new selection is caret position in new composition string. Therefore, it's not used for the adjustment. This causes that stored composition start offset is always the start of the previous composition (if the previous patch didn't change EnsureToCacheSelection() behavior). So, IMContextWrapper needs to compute proper composition start offset in this case. The simplest fix is, modifying selection at #2 as which will be occurred in focused editor. So, this patch makes the selection cache collapsed to the end of committing string. Note that actual selection may be different if JS changes selection and/or the text in the focused editor. However, it doesn't matter. IMContextWrapper should behave as expected while current composition is active. MozReview-Commit-ID: 221mDUd8yRP --HG-- extra : rebase_source : 571b2de85ed6ea1fdadea73b7f95507937cc60e9

… collapsed to the end of composition r=m_kato When you start new composition during converting with Mozc in e10s mode, the following things occur: 1. Mozc commits previous composition. 2. Gecko dispatches eCompositionCommit event. 3. Mozc sets new composition string (skipping composition start signal). 4. Gecko dispatches eCompositionStart and eCompositionChange event. 5. Selection is changed asynchronously. 6. Gecko sets position of IME windows. At mozilla#4, Gecko stores start of composition as selection start, then, trying to adjust it at mozilla#5. However, new selection is caret position in new composition string. Therefore, it's not used for the adjustment. This causes that stored composition start offset is always the start of the previous composition (if the previous patch didn't change EnsureToCacheSelection() behavior). So, IMContextWrapper needs to compute proper composition start offset in this case. The simplest fix is, modifying selection at mozilla#2 as which will be occurred in focused editor. So, this patch makes the selection cache collapsed to the end of committing string. Note that actual selection may be different if JS changes selection and/or the text in the focused editor. However, it doesn't matter. IMContextWrapper should behave as expected while current composition is active. MozReview-Commit-ID: 221mDUd8yRP

Fix a bunch of linker errors

…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

…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

…type when reframing. r=emilio If a <details> is a multi-column container, and has a column-span child inside, aFrame can be ColumnSetWrapper or column-span-wrapper frame (due to GetInsertionPrevSibling()'s modification). The latter case is handled by "Situation #5 in WipeContainingBlock(), and can be reproduced by changing `<article>` tag to `<details>` in testing/web-platform/tests/css/css-multicol/multicol-span-all-dynamic-add-005.html In any case, aFrame might end up in a frame generated by the <details> element. I feel the assertion to check frame types might not be very useful. Let's remove it. Differential Revision: https://phabricator.services.mozilla.com/D45585 --HG-- extra : moz-landing-system : lando

…type when reframing. r=emilio If a <details> is a multi-column container, and has a column-span child inside, aFrame can be ColumnSetWrapper or column-span-wrapper frame (due to GetInsertionPrevSibling()'s modification). The latter case is handled by "Situation mozilla#5 in WipeContainingBlock(), and can be reproduced by changing `<article>` tag to `<details>` in testing/web-platform/tests/css/css-multicol/multicol-span-all-dynamic-add-005.html In any case, aFrame might end up in a frame generated by the <details> element. I feel the assertion to check frame types might not be very useful. Let's remove it. Differential Revision: https://phabricator.services.mozilla.com/D45585

…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

…he() r=dragana frame #5 of report https://crash-stats.mozilla.org/report/index/4dca6cb1-8d45-4bf5-8836-216810200217 This crash was rather obvious in retrospect, but I missed it because I was looking at the wrong thing. We're not actually crashing in FlushCache, instead mHostResolver is null in nsDNSService::Observe What made it obvious is frame #5 of report https://crash-stats.mozilla.org/report/index/4dca6cb1-8d45-4bf5-8836-216810200217 Included here because crash reports expire: ``` 1 libxul.so nsHostResolver::FlushCache(bool) netwerk/dns/nsHostResolver.cpp:740 2 libxul.so nsDNSService::Observe(nsISupports*, char const*, char16_t const*) netwerk/dns/nsDNSService2.cpp:1132 3 libxul.so nsObserverList::NotifyObservers(nsISupports*, char const*, char16_t const*) xpcom/ds/nsObserverList.cpp:66 4 libxul.so nsObserverService::NotifyObservers(nsISupports*, char const*, char16_t const*) xpcom/ds/nsObserverService.cpp:295 5 libxul.so DecreasePrivateDocShellCount() docshell/base/nsDocShell.cpp:306 6 libxul.so nsDocShell::Destroy() docshell/base/nsDocShell.cpp:5076 ``` See the code points to this line: https://hg.mozilla.org/releases/mozilla-esr68/annotate/ef373efc995d9350a676c4c231b344d173423e8a/docshell/base/nsDocShell.cpp#l306 As we can see, it emits the "last-pb-context-exited" notification, and nsDNSService tries to call FlushCache. However, it appears this notification may be called after we get the shutdown notification and we null out the pointer. It's unclear why this crash was not noticed before bug 1450893 landed. Depends on D63107 Differential Revision: https://phabricator.services.mozilla.com/D63108 --HG-- extra : moz-landing-system : lando

…he(). r=dragana, a=RyanVM frame #5 of report https://crash-stats.mozilla.org/report/index/4dca6cb1-8d45-4bf5-8836-216810200217 This crash was rather obvious in retrospect, but I missed it because I was looking at the wrong thing. We're not actually crashing in FlushCache, instead mHostResolver is null in nsDNSService::Observe What made it obvious is frame #5 of report https://crash-stats.mozilla.org/report/index/4dca6cb1-8d45-4bf5-8836-216810200217 Included here because crash reports expire: ``` 1 libxul.so nsHostResolver::FlushCache(bool) netwerk/dns/nsHostResolver.cpp:740 2 libxul.so nsDNSService::Observe(nsISupports*, char const*, char16_t const*) netwerk/dns/nsDNSService2.cpp:1132 3 libxul.so nsObserverList::NotifyObservers(nsISupports*, char const*, char16_t const*) xpcom/ds/nsObserverList.cpp:66 4 libxul.so nsObserverService::NotifyObservers(nsISupports*, char const*, char16_t const*) xpcom/ds/nsObserverService.cpp:295 5 libxul.so DecreasePrivateDocShellCount() docshell/base/nsDocShell.cpp:306 6 libxul.so nsDocShell::Destroy() docshell/base/nsDocShell.cpp:5076 ``` See the code points to this line: https://hg.mozilla.org/releases/mozilla-esr68/annotate/ef373efc995d9350a676c4c231b344d173423e8a/docshell/base/nsDocShell.cpp#l306 As we can see, it emits the "last-pb-context-exited" notification, and nsDNSService tries to call FlushCache. However, it appears this notification may be called after we get the shutdown notification and we null out the pointer. It's unclear why this crash was not noticed before bug 1450893 landed. Depends on D63107 Differential Revision: https://phabricator.services.mozilla.com/D63108 --HG-- extra : source : 1e00af5facbe250e8bb09bce26ec29b39d655fa1 extra : amend_source : 733fbd80519eb29a282aa3e81691fa45b042db1b

…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

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

…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

2021-05-06 Martin Thomson <mt@lowentropy.net> * gtests/pk11_gtest/pk11_hpke_unittest.cc: Bug 1709750 - Disable HPKE test when fuzzing, r=bbeurdouche [1d066793c349] [tip] 2021-05-05 Benjamin Beurdouche <bbeurdouche@mozilla.com> * lib/freebl/ppc-gcm-wrap.c, lib/freebl/ppc-gcm.h: Bug 1566124 - Clang format run. r=beurdouche [cb714d62058c] 2021-05-05 mamonet <maamoun.tk@gmail.com> * lib/freebl/Makefile, lib/freebl/freebl.gyp, lib/freebl/ppc-gcm- wrap.c, lib/freebl/ppc-gcm.h, lib/freebl/ppc-gcm.s, lib/freebl/rijndael.c: [1133fef2f7ce] 2021-03-17 Martin Thomson <mt@lowentropy.net> * gtests/common/testvectors/hpke-convert.py, gtests/common/testvectors/hpke-vectors.h, lib/pk11wrap/pk11hpke.c, lib/pk11wrap/pk11hpke.h: Bug 1699021 - Add AES-256-GCM to HPKE, r=bbeurdouche [9fa53d717386] * automation/abi-check/expected-report-libssl3.so.txt, cmd/selfserv/selfserv.c, gtests/ssl_gtest/libssl_internals.c, gtests/ssl_gtest/libssl_internals.h, gtests/ssl_gtest/tls_connect.cc, gtests/ssl_gtest/tls_connect.h, gtests/ssl_gtest/tls_ech_unittest.cc, lib/ssl/sslexp.h, lib/ssl/sslsock.c, lib/ssl/sslt.h, lib/ssl/tls13ech.c, lib/ssl/tls13ech.h, lib/ssl/tls13exthandle.c, lib/ssl/tls13hashstate.c, lib/ssl/tls13hashstate.h: Bug 1698419 - ECH -10 updates, r=bbeurdouche The main changes here are: * an update to HPKE -08 * a move to the single-byte configuration ID * reordering of ECHConfig The addition of the explicit configuration ID means that the API for constructing ECHConfig(List) needs to change. That means a name change, unfortunately. I took the opportunity to make further changes to the arguments. [fa93bd88b690] 2021-03-16 Martin Thomson <mt@lowentropy.net> * coreconf/config.gypi, coreconf/config.mk, gtests/common/testvectors/hpke-convert.py, gtests/common/testvectors/hpke-vectors.h, gtests/pk11_gtest/pk11_hpke_unittest.cc, gtests/ssl_gtest/ssl_auth_unittest.cc, gtests/ssl_gtest/ssl_tls13compat_unittest.cc, gtests/ssl_gtest/tls_ech_unittest.cc, lib/pk11wrap/pk11hpke.c, lib/pk11wrap/pk11hpke.h, lib/pk11wrap/pk11pub.h, lib/ssl/tls13ech.c: Bug 1692930 - Update HPKE to final version, r=bbeurdouche This adds the final HPKE version string. This removes the draft version markers from the implementation and stops tracking the draft version with the exported syntax. I've added the script that I used to convert the JSON test vectors from the specification; that should allow us to pick up new tests relatively easily, especially if we need to add new algorithms. This change breaks several ECH test cases. As fixing those tests is extraordinarily fiddly, I'm going to defer making those changes until we need to update ECH. As we can't land this code until ECH is updated to depend on the final HPKE and until we have coordinated with servers on when the ECH update can be deployed, it should be OK to defer. In short, don't land this without the matching ECH changes. [e78141a928f4] 2021-05-04 Robert Relyea <rrelyea@redhat.com> * automation/abi-check/expected-report-libnss3.so.txt, cmd/lib/basicutil.h, cmd/lib/secutil.c, cmd/lib/secutil.h, cmd/pk12util/pk12util.c, cmd/pp/pp.c, doc/pk12util.xml, doc/pp.xml, lib/nss/nss.def, lib/pk11wrap/pk11akey.c, lib/pk11wrap/pk11pub.h, lib/pkcs12/p12d.c, lib/pkcs12/p12e.c, lib/pkcs12/p12local.c, lib/pkcs12/p12local.h, lib/pkcs12/p12plcy.c, lib/util/secoidt.h, tests/tools/tools.sh: Bug 1707130 NSS should use modern algorithms in PKCS#12 files by default r=mt Also fixes: Bug 452464 pk12util -o fails when -C option specifies AES or Camellia ciphers Related: Bug 1694689 Firefox should use modern algorithms in PKCS#12 files by default Bug 452471 pk12util -o fails when -c option specifies pkcs12v2 PBE ciphers The base of this fix is was a simple 3 line fix in pkcs12.c, changing the initial setting of cipher and cert cipher. Overview for why this patch is larger than just 3 lines: 1. First issue was found in trying to change the mac hashing value. a. While the decrypt side knew how to handle SHA2 hashes, the equivalent code was not updated on the encrypt side. I refactored that code and placed the common function in p12local.c. Now p12e.c and p12d.c share common code to find the required function to produce the mac key. b. The prf hmac was hard coded to SHA1. I changed the code to pass the hmac matching the hashing algorithm for the mac. This required changes to p12e.c to calculate and pass the new hmac as well and adding new PK11_ExportEncryptedPrivateKey and PK11_ExportEncryptedPrivKey to take the PKCS #5 v2 parameters. I also corrected an error which prevented pkcs12 encoding of ciphers other than AES. 2. Once I've made my changes, I realized we didn't have a way of testing them. While we had code that verified that particular sets of parameters for pkcs12 worked together and could be listed and imported, we didn't have a way to verify what algorithms were actually generated by our tools. a. pk12util -l doesn't list the encryption used for the certs, so I updated pp to take a pkcs12 option. In doing so I had to update pp to handle indefinite encoding when decoding blocks. I also factored that decoding out in it's own function so the change only needed to be placed once. Finally I renabled a function which prints the output of an EncryptedPrivate key. This function was disabled long ago when the Encrypted Private key info was made private for NSS. It has since been exported, so these functions could easily be enabled (archeological note: I verified that this disabling was not a recent think I found I had done it back when I still have a netscape email address;). b. I updated tools.sh to us the new pp -t pkcs12 feature to verify that the key encryption, cert encryption, and hash functions matched what we expected when we exported a new key. I also updated tools.sh to handle the new hash variable option to pk12util. c. I discovered several tests commented out with comments that the don't work. I enabled those tests and discovered that they can now encrypt, but the can't decrypt because of pkcs12 policy. I updated the policy code, but I updated it to use the new NSS system wide policy mechanism. This enabled all the ciphers to work. There is still policy work to do. The pk12 policy currently only prevents ciphers from use in decrypting the certificates, not decrypting the keys and not encrypting. I left that for future work. 3. New options for pp and pk12util were added to the man pages for these tools. -------------------------------------------------------------------- ------- With that in mind, here's a file by file description of the patch: automation/abi-check/expected-report-libnss3.so.txt -Add new exported functions. (see lib/nss/nss.def) cmd/lib/basicutil.h: -Removed the HAVE_EPV_TEMPLATE ifdefs (NSS has exported the Encrypted Private Key data structure for a while now. cmd/lib/secutil.c: global: Updated several functions to take a const char * m (message) rather than a char * m global: Made the various PrintPKCS7 return an error code. global: Added a state variable to be passed around the various PKCS7 Print functions. It gives the proper context to interpret PKCS7 Data Content. PKCS 12 used PKCS7 to package the various PKCS12 Safes and Bags. -Updated SECU_StripTagAndLength to handle indefinite encoding, and to set the Error code. -Added SECU_ExtractDERAndStep to grab the next DER Tag, Length, and Data. -Updated secu_PrintRawStringQuotesOptional to remove the inline DER parsing and use SECU_ExtractDERAndStep(). -Updated SECU_PrintEncodedObjectID to return the SECOidTag just like SECU_PrintObjectID. -Renable SECU_PrintPrivateKey -Added secu_PrintPKCS12Attributes to print out the Attributes tied to a PKCS #12 Bag -Added secu_PrintPKCS12Bag to print out a PKCS #12 Bag -Added secu_PrintPKCS7Data, which uses the state to determine what it was printing out. -Added secu_PrintDERPKCS7ContentInfo which is identical to the global function SECU_PrintPKCS7ContentInfo except it takes a state variable. The latter function now calls the former. -Added secu_PrintPKCS12DigestInfo to print the Hash information of the Mac. DigestInfo is the name in the PKCS 12 spec. -Added secu_PrintPKCS12MacData to print the Mac portion of the PKCS 12 file. -Added SECU_PrintPKCS12 to print otu the pkcs12 file. cmd/lib/secutil.h -Added string for pkc12 for the command line of pp reenabled SECU_PrintPrivateKey -Added SECU_PrintPKCS12 for export. cmd/pk12util/pk12util.c -Added the -M option to specify a hash algorithm for the mac. updated P12U_ExportPKCS12Object: pass the hash algorithm to the PasswordIntegrity handler. -Added PKCS12U_FindTagFromString: generalized string to SECOidTag which only filters based on the oid having a matching PKCS #11 mechanism. updated PKCS12U_MapCipherFromString to call use PKCS12U_FindTagFromString to get the candidate tag before doing it's post processing to decide if the tag is really an encryption algorithm. -Added PKCS12U_MapHashFromString with is like MapCipherFromString except it verifies the resulting tag is a hash object. -Updated main to 1) change the default cipher, change the default certCipher, and process the new hash argument. NOTE: in the old code we did not encrypt the certs in FIPS mode. That's because the certs were encrypted with RC4 in the default pkcs12 file, which wasn't a FIPS algorithm. Since AES is, we can use it independent on whether or not we are in FIPS mode. cmd/pp/pp.c -Added the pkcs12 option which calls SECU_PrintPKCS12 from secutil.c lib/nss/nss.def -Add exports to the new PK11_ExportEncryptedPrivKeyInfoV2 and PK11_ExportEncryptedPrivateKeyInfoV2 (V2 means PKCS 5 v2, not Version 2 of ExportEncrypted*Info). -Add export for the old HASH_GetHMACOidTagByHashOidTag which should have been exported long ago to avoid the proliferation of copies of this function in places like ssl. lib/pk11wrap/pk11akey.c -Add PK11_ExportEncryptedPrivKeyInfoV2 (which the old function now calls), which takes the 3 PKCS 5 v2 parameters. The underlying pkcs5 code can fill in missing tags if necessary, but supplying all three gives the caller full control of the underlying pkcs5 PBE used. -Add PK11_ExportEncryptedPrivateKeyInfoV2, same as the above function except it takes a cert which is used to look up the private key. It's the function that pkcs12 actually uses, but the former was exported for completeness. lib/pk11wrap/pk11pub.h -Added the new PK11_ExportEncryptedPriv*KeyInfoV2 functions. lib/pkcs12/p12d.c -Remove the switch statement and place it in p12local.c so that p12e.c can use the same function. lib/pkc12/p12e.c -Remove the unnecessary privAlg check so we can encode any mechanism we support. This only prevented encoding certificates in the pk12 file, not the keys. -add code to get the hmac used in the pbe prf from the integrity hash, which is under application control. -Do the same for key encryption, then use the new PK11_ExportEncryptedPrivateKeyInfo to pass that hash value. -Use the new sec_pkcs12_algtag_to_keygen_mech so there is only one switch statement to update rather than 2. -Update the hash data to old the length of the largest hash rather than the length of a SHA1 hash. lib/pkcs12/p12local.c - Add new function new sec_pkcs12_algtag_to_keygen_mech to factor out the common switch statement between p12e and p12d. lib/pkcs12/p12local.h -Export the new sec_pkcs12_algtag_to_keygen_mech lib/pkcs12/p12plcy.c -Map the old p12 policy functions to use the new NSS_GetAlgorithmPolicy. We keep the old table so that applications can change the policy with the old PKCS12 specific defines (so the old code keeps working). NOTE: policies now default to true rather than false. lib/util/secoidt.h -Add new NSS_USE_ALG_IN_PKCS12 used by pk11plcy.c NOTE: I have not updated the policy table in pk11wrap/pk11pars.c, so we can't yet control pkcs12 policy with the nss system policy table. That's a patch for another time. test/tools/tool.sh -global: Remove trailing spaces -global: DEFAULT is changed to 'default' -Update the PBE mechanism to exactly match the string in secoid.c. PKCS #12 does case independent compares, so case doesn't matter there, but now I'm comparing to the output of pp, and I didn't want to spend the time to figure out case independent compares in bash. -Add our defauts and shell variables at the top so there are easy to change in the future. export_with_*** have all been colapsed into a single export_p12_file which handles taking 'default' and turning off that argument. -Add for loops for the hash functions. -Restore the camellia ciphers back now that they work. -Restore the pkcs12V2pbe back now that they work. -Collect various pbe types into single variables and use those variables in loops -Reduce the number of tests ran in optimized mode (which takes 60x the time to do a pbe then than debug mode based on a larger iterator). -Add verify_p12 which dumps out the p12 file and makes sure the expected CERT_ENCRYPTION, KEY_ENCRYPTION, and HASH are used. doc/pp.xml -Add pkcs12 option doc/pk12util.xml -Add -M option -Update synopsis with options in the description but not in the synopsis [0a1687e1b39e] Differential Revision: https://phabricator.services.mozilla.com/D114584

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

…login manager marks an focus field. r=tgiles In nsAutocompleteController::HandleKeyNavigation, we might trigger a search operation (or open the popup) However, when we find there is already a search result received previously, and the search string is the same as the current one, we won't trigger a new search[1] because the result should be the same. This might be true for most of the cases, but not true when clients that perform the search is differnt. As far as I know, there are at least 3 different autocomplete clients: form history, CC/Address autocomplete, and login manager. For example, the same search string might return a different result when it is searched by the login manager and by the form history component. Here is how the intermittent occurs: 1. The page is loaded 2. Password field is detected so the login manager fetches the login data from the parent asynchronously 3. The testcase continues to run. The username field is focused 4. Autocomplete search for the focus field is triggered. Since the login manager has not yet told FormFillController this is a field we care, we search the form history and get an empty result. 5. Login data is sent from parent to child, _fillForm is called. The LoginManagerChild calls `MarkAsLoginManagerField` 6. Key event occurs on the field. Autocomplete search is triggered again. However, the search is not executed because [1] 7. Popup is not shown. Testcase timeout. When #5 occurs before #3, the autocomplete search in #4 will be processed by the login manager, and we will get the result and open the popup in this case In the current architecture, I don't see an easy way that we can distinguish whether the autocomplete client is different in nsAutocompleteController. So instead of doing it in nsAutocompleteController, this patch fixes this issue in FormFillController. In FormFillController, when we call `MarkAsLoginManagerField` on a focus field, we call ResetInternalState() to tell nsAutocompleteController to clear previous search result. [1] https://searchfox.org/mozilla-central/rev/fb8d77331582639ea6848a61dd8ee812fac31b77/toolkit/components/autocomplete/nsAutoCompleteController.cpp#516-521 Differential Revision: https://phabricator.services.mozilla.com/D131237

* Add base riscv64 * Add base simulator * add base disasm * add base assembler * fix debug build * fix style

Upstream commit: https://webrtc.googlesource.com/src/+/6ced79beecdf6ec669840f3ca9d9695cfdbf9376 Add additional checks in case of early portal error In case ScreenCast portal fails right at the beginning, we need to check the response before trying to get session handle to avoid accessing non-existing portal data. Also on early failure do not continue making source request if we failed before and don't have session handle. (cherry picked from commit 65a9a515b51be1050bbb6fcb1edfbdff706434bf) Bug: webrtc:13429, chromium:1363783 Change-Id: I2bfbd2c6e96e3cda1e62aa9dc07f66d4c7496b53 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272400 Reviewed-by: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Mark Foltz <mfoltz@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#37872} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275961 Commit-Queue: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/5249@{#5} Cr-Branched-From: 7aaeb5a270ba23f5844f7301a50aaff9b6ca6126-refs/heads/main@{#37825}

Upstream commit: https://webrtc.googlesource.com/src/+/64edb15e1e5bb86bbcb78f0e8be0a6559097f3f3 Make P2PTransportChannel implement IceAgentInterface (#5/n) This functionally no-op change adds the methods to allow an active ICE controller to manipulate the connection used by the ICE transport. Most methods reuse existing code, this will be explicitly marked for cleanup with a follow-up CL which adds active ICE controller support. Non-trivial changes are needed for P2PTransportChannel unit tests to cover the new code, and these are also being added in a follow-up CL. Bug: webrtc:14367, webrtc:14131 Change-Id: I4f012efcd8cb5766eb8c6f0872de50f8375f3a73 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275301 Reviewed-by: Jonas Oreland <jonaso@webrtc.org> Commit-Queue: Sameer Vijaykar <samvi@google.com> Cr-Commit-Position: refs/heads/main@{#38081}

Upstream commit: https://webrtc.googlesource.com/src/+/4005adc6d639035fdd5323861d9a2fc6bd946e99 [M107] ice: include tiebreaker in computation of foundation attribute the foundation attribute is currently calculated as CRC32(baseaddress, protocol, relayprotocol) which is a way to satisfy the requirements from https://www.rfc-editor.org/rfc/rfc5245#section-4.1.1.3 However, this leaks the base address which defeats the MDNS obfuscation described in https://datatracker.ietf.org/doc/draft-ietf-mmusic-mdns-ice-candidates/ since the CRC32 can be reversed using a table lookup as shown in https://github.com/niespodd/webrtc-local-ip-leak/ To defeat that lookup, "seed" the CRC32 with the ICE tie-breaker which is a randomly picked unsigned 64 bit integer described in https://www.rfc-editor.org/rfc/rfc5245#section-5.2 The tie-breaker is not known to Javascript and adding it scopes the foundation within the peer connection as described in section 4.1.1.3 To manually test (preferably with a DCHECK for IceTiebreaker() in ComputeFoundation) - gather candidates twice on https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ and observe that the foundations are not the same after this change - create two RTCPeerConnections with {iceCandidatePoolSize: 1}, create a datachannel, call setLocalDescription, inspect the candidates and observe that the foundations are not the same after this change. Unit test changes have been split into a separate CL for easier integration. BUG=webrtc:14605,chromium:1378916 (cherry picked from commit 08b882d762edadb9797334859d915c5c1e34896b) Change-Id: I6bbad1635b48997b00ae74d251ae357bf8afd12f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280621 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Jonas Oreland <jonaso@webrtc.org> Commit-Queue: Harald Alvestrand <hta@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#38485} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281421 Commit-Queue: Philipp Hancke <phancke@microsoft.com> Cr-Commit-Position: refs/branch-heads/5304@{#5} Cr-Branched-From: 024bd84ca1cf7d3650c27912a3b5bfbb54da152a-refs/heads/main@{#38083}

Upstream commit: https://webrtc.googlesource.com/src/+/93081d594f7efff72958a79251f53731b99e902b [Merge M108] Ensure video frame buffer is still decodable before decoding This ensures that if for some reason, the frame buffer becomes undecodable while waiting to decode a frame, the decoding is halted. This also guards against receiving an empty temporal unit from the frame buffer, even though this should never happen when the frame buffer has a decodable temporal unit. (cherry picked from commit 8fe5579136c82b558022fe7d1393fa248b151eae) Bug: chromium:1378253, chromium:1361623 Change-Id: I8c4c897bf474d5cbda5f0f357781bf1dc0701fe4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280701 Commit-Queue: Evan Shrubsole <eshr@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#38494} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281720 Cr-Commit-Position: refs/branch-heads/5359@{#5} Cr-Branched-From: fb3bd4a01d7c840dfe7b3efa144c0fbcb6a97fef-refs/heads/main@{#38387}

Upstream commit: https://webrtc.googlesource.com/src/+/218b56e516386cd57c7513197528c3124bcd7ef3 Fix Destruction inside WGC Callback If we are notified of the destruction of the window before a CaptureFrame call can fail, then we may end up attempting to destroy the underlying WGC object inside it's own event handler. This can be problematic, as the class itself may want to run other code. Instead, we just unsubscribe and signal that any future CaptureFrame calls should reject. This also removes setting "is_capture_started_=false" in the item closed handler, as all that served to do is cause the WgcCapturerWin code to attempt to restart the capturer, and somewhat muddies up our metrics. (cherry picked from commit 318cf28945d80a0ac6f09382e507c95e649cc4c1) Bug: chromium:1413005 No-Try: True Change-Id: Ibccb7a2e7ce531ba80b4b331b9bc2cda0ff75f4e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292762 Auto-Submit: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#39275} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293246 Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5481@{#5} Cr-Branched-From: 2e1a9a4ae0234d4b1ea7a6fd4188afa1fb20379d-refs/heads/main@{#38901}

Upstream commit: https://webrtc.googlesource.com/src/+/9089c0d814b11739a7e323c6a9cb03bfad149ea8 [Merge-111] Preserve mid of sections added with AddTrack after a rollback Since AddTrack now has an implicit init_encodings value, it will also have a StableState saved when associating a transceiver. That state may not have a saved mid and mline_index, and so on a rollback, it could blindly reset the mid and mline_index of an associated transceiver. This is wrong, the mid and mline_index of associated transceivers should only be updated when the StableState objects actually have one saved. # Try bots not possible due to # https://webrtc-review.googlesource.com/c/src/+/292820 NOTRY=True (cherry picked from commit b3d424cd484dd7a109547ca7be7f1575a29df7e7) Bug: chromium:1424238 Change-Id: I8e80a04cd072d90200ca7643de892c0ef29b1f1a Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297920 Commit-Queue: Florent Castelli <orphis@webrtc.org> Reviewed-by: Henrik Boström <hbos@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#39577} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/297984 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/branch-heads/5563@{#5} Cr-Branched-From: 6c032cb8356b0d3f717c4fcf50796241f2bba6c2-refs/heads/main@{#39207}

Upstream commit: https://webrtc.googlesource.com/src/+/a624ee1be7a11e795a849edb2a27dc1137d2b63d [M114] Avoid touching channel after OnSctpDataChannelClosed (cherry picked from commit eec1810760ccbdf95c68ed0d2c2ae10a8575551a) Bug: chromium:1454086 Change-Id: I39573b706c4031d091c45a182b13cb3b2dba6233 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309920 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40332} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310922 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/5735@{#5} Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}

Upstream commit: https://webrtc.googlesource.com/src/+/6603550a4279b4b68b8b763523370dc8e010500c [Merge-M115] Support conversion of VP9 non-flexible mode to generic descriptor for non-layered streams only. When VP9 HW encoders don't provide any metadata a minimal non-flexible mode structure is generated for the stream: (https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/blink/renderer/platform/peerconnection/rtc_video_encoder.cc;l=1275-1298;drc=f80633b34538615fcb73515ad8c4bc56a748abfe). (cherry picked from commit 4e0bf2e5a1946b8f94f4b23b57b3e89a25fce65d) Bug: chromium:1455428, b/286993839, b/287458300 Change-Id: I72628f20927d685e9c8ba1744126d763896bd804 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309380 Commit-Queue: Philip Eliasson <philipel@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Reviewed-by: Henrik Boström <hbos@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40316} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309921 Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/branch-heads/5790@{#5} Cr-Branched-From: 2eacbbc03a4a41ea658661225eb1c8fc07884c33-refs/heads/main@{#40122}

We already cherry-picked this when we vendored 8fbabf340d. Upstream commit: https://webrtc.googlesource.com/src/+/626d408ba5d0ae5b1f6b66a7cf244a85ea66c11e [M116] Revert mid check in SdpOfferAnswerHandler::CreateDataChannel. This check was added here: https://webrtc-review.googlesource.com/c/src/+/300544 When createOffer is used before createAnswer, this check would cause SetupDataChannelTransport_n to not be called for the remote channel. (cherry picked from commit 299cdc9057fb8925f1692ac8c7573f51b7872df6) Bug: webrtc:15258, chromium:1458937 Change-Id: Ifdab35d1b0260ff03fef4beff13acf8090d59d8f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310460 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40357} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312123 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/5845@{#5} Cr-Branched-From: f80cf814353d11a9f22bef5ce5e8868f2c72f0d0-refs/heads/main@{#40319}

…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

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}

…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

* FIDEFE-4643 - Use value object in design-tokens.json By using the composite design token value structure, we gain flexibility in handling themed and non-themed tokens as well as other cases that we are not aware of. For example, this composite value structure can be used to handle prefers-contrast theming, forced-colors (HCM) theming, etc. We also add the ability to use "default" as the default value of tokens. This handles the case where a token has the same value in light and dark mode but has a different value in perfers-contrast or forced-colors mode. Currently "default" is the highest priority property of the value object. If you have "light", "dark" and "default" for a token's value, then the "default" property will be in the generated token and not the "light" or "dark" property values. * fix broken matcher function in lightDarkTransform

Upstream commit: https://webrtc.googlesource.com/src/+/79ba9b0b2b28e49ecc32992ff9163917299beedc [M121] Disable the use of CGDisplayStreamCreate() for desktop capture on Sonoma CGDisplayStreamCreate is an deprecated API. It was believed that the use of it was disabled on Sonoma through the setting allow_iosurface = false [1], which causes the thumbnails to be created by the API CGDisplayCreateImage. This API is not marked as deprecated at the moment. However, although the thumbnails are created through CGDisplayCreateImage, CGDisplayStreamCreate() is still called and runs in the background. This makes the capture chip appear. No capture chip appears if this CL is landed and the ScreenCaptureKit thumbnail capturer is enabled, --enable-features="ScreenCaptureKitMac,ScreenCaptureKitStreamPickerSonoma,ThumbnailCapturerMac:capture_mode/sc_screenshot_manager" [1] https://chromium-review.googlesource.com/c/chromium/src/+/4892397 (cherry picked from commit fb99c6ebb57754e4b764a63dfae7f62ec272ba6b) Bug: chromium:1486851 No-Try: True Change-Id: I3422efffc57dcb3e8965f19a5eca7f2a95d62da1 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/334721 Reviewed-by: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Johannes Kron <kron@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#41563} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/335740 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/6167@{#5} Cr-Branched-From: ece5cb83715dea85617114b6d4e981fdee2623ba-refs/heads/main@{#41315}

* FIDEFE-4643 - Use value object in design-tokens.json By using the composite design token value structure, we gain flexibility in handling themed and non-themed tokens as well as other cases that we are not aware of. For example, this composite value structure can be used to handle prefers-contrast theming, forced-colors (HCM) theming, etc. We also add the ability to use "default" as the default value of tokens. This handles the case where a token has the same value in light and dark mode but has a different value in perfers-contrast or forced-colors mode. Currently "default" is the highest priority property of the value object. If you have "light", "dark" and "default" for a token's value, then the "default" property will be in the generated token and not the "light" or "dark" property values. * fix broken matcher function in lightDarkTransform

@page

…inting background., a=testonly Automatic update from web-platform-tests Get border/padding from fragment when painting background. Since @page border box layout objects aren't in the the layout tree, any code that wants to walk up the tree to find the containing block will be in for a surprise. This would happen if percentage-based @page padding was used [1]. Recomputing padding during painting when we have already done it during layout is rather pointless anyway. Read it out directly from the fragment. [1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent() #2 blink::LayoutBoxModelObject::ComputedCSSPadding() #3 blink::LayoutBoxModelObject::PaddingTop() #4 blink::LayoutBoxModelObject::PaddingOutsets() #5 blink::BoxPainterBase::PaintFillLayer() #6 blink::BoxPainterBase::PaintFillLayers() #7 blink::BoxFragmentPainter::PaintBackground() Bug: 40286153 Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469 Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1300711} -- wpt-commits: 601b701a9d708b48a9cddae1ac15963d61be7964 wpt-pr: 46252

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}

Gozala reviewed Jan 29, 2014
View reviewed changes

Bug 964545 Add-on SDK page-mods are now debuggable

4e2794d

rainemak pushed a commit to rainemak/gecko-dev-mirror that referenced this pull request Mar 10, 2014

Merge pull request mozilla#5 from tmeshkova/rpm-packaging

ffcf2a4

update nemo rpm packaging

erikvold closed this May 19, 2014

martinthomson pushed a commit to martinthomson/gecko-dev that referenced this pull request Sep 17, 2014

Merge pull request mozilla#5 from martinthomson/dirs

0eaa478

Making directories

walac pushed a commit to walac/gecko-dev that referenced this pull request Oct 28, 2014

Merge pull request mozilla#5 from walac/bugz/1087456

ff0dddb

Bug 1087456

weilonge added a commit to weilonge/gecko-dev that referenced this pull request Nov 10, 2015

Merge pull request mozilla#5 from MozCloudStorage/unidisk_gecko

e906129

Unidisk gecko

JuniorHsu pushed a commit to JuniorHsu/gecko-dev that referenced this pull request Jun 1, 2016

Merge pull request mozilla#5 from MDTsai/2.6_Bug_1197751

9f233a9

Bug 1197751 - Add event shutter of RemoteControlService; a=jocheng

lissyx pushed a commit to lissyx/gecko-dev that referenced this pull request Feb 15, 2019

Merge pull request mozilla#5 from walac/gonk-experiment

02a5b21

Fix a bunch of linker errors

bvaughn pushed a commit to bvaughn/gecko-dev that referenced this pull request Apr 5, 2022

Fix showing blank new tabs by default, fixes mozilla#5

75475d8

luyahan added a commit to luyahan/gecko-dev that referenced this pull request Aug 22, 2022

Add base riscv64 file (mozilla#5)

2894cf7

* Add base riscv64 * Add base simulator * add base disasm * add base assembler * fix debug build * fix style

luyahan added a commit to luyahan/gecko-dev that referenced this pull request Aug 23, 2022

Add base riscv64 file (mozilla#5)

554c790

* Add base riscv64 * Add base simulator * add base disasm * add base assembler * fix debug build * fix style

luyahan added a commit to luyahan/gecko-dev that referenced this pull request Aug 23, 2022

Add base riscv64 file (mozilla#5)

e7b777e

* Add base riscv64 * Add base simulator * add base disasm * add base assembler * fix debug build * fix style

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bug 964545 Add-on SDK page-mods are now debuggable #5

Bug 964545 Add-on SDK page-mods are now debuggable #5

erikvold commented Jan 28, 2014

Gozala Jan 29, 2014

Gozala Jan 29, 2014


		// when the window is destroyed, eliminate the associated globals cache

		Services.obs.addObserver(function observer(subject, topic, data) {

Bug 964545 Add-on SDK page-mods are now debuggable #5

Bug 964545 Add-on SDK page-mods are now debuggable #5

Conversation

erikvold commented Jan 28, 2014

Gozala Jan 29, 2014

Choose a reason for hiding this comment

Gozala Jan 29, 2014

Choose a reason for hiding this comment