Bump express from 2.5.11 to 4.17.1 in /testing/xpcshell/node-spdy/examples/twitlog #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [express](https://github.com/expressjs/express) from 2.5.11 to 4.17.1. - [Release notes](https://github.com/expressjs/express/releases) - [Changelog](https://github.com/expressjs/express/blob/master/History.md) - [Commits](expressjs/express@2.5.11...4.17.1) Signed-off-by: dependabot[bot] <[email protected]>
dependabot
bot
added
the
dependencies
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 28, 2019
UltraBlame original commit: 0f9b4d3635b6d0c580ca2eb36250ce6e72535ecf
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 28, 2019
…tml. r=bz This patch also removes the debug statements. UltraBlame original commit: 49b130f753d3837eb460d296be14499c9966a603
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
…posed by the fix for bug 811102, r=markh UltraBlame original commit: a06a34a849551211c9352c79d09678f31faa1e06
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
Landing attempt #2. Some excessively picky people seem to insist that it should successfully compile. UltraBlame original commit: 5718a26eb442da4dc52b5666db66d65ff8fe4735
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
bot
deleted the
dependabot/npm_and_yarn/testing/xpcshell/node-spdy/examples/twitlog/express-4.17.1
branch
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
UltraBlame original commit: e5b6545901b0c7437c8e13581c154e790085dc98
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
UltraBlame original commit: b5c0c5b2a6d465677535d5365b83fd41637a220d
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
UltraBlame original commit: d57032f0b27761d3495b29dbda57c1da36ac1054
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
UltraBlame original commit: 932964100cd2f802c369d335804a762cfad1d2a3
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
…onger before trying to check the location bar in a new window UltraBlame original commit: 56a63eee73b491a465084beefd03057c6a510067
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
…ct for JS-implemented webidl in an attempt to reopen the CLOSED TREE. r=khuey UltraBlame original commit: 0868beaeab71617b34ec42dcac6dbb8a42ad9de0
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
UltraBlame original commit: 2f41b8eb22b566cdca02952786c519e81fb2a6d9
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
======== https://hg.mozilla.org/integration/gaia-central/rev/3c7ae072e684 Author: Kyle Machulis <kylenonpolynomial.com> Desc: Merge pull request #16096 from qdot/969650-move-customization-sample-to-gaia Bug 969650 - Add customization sample to gaia ======== https://hg.mozilla.org/integration/gaia-central/rev/8715b511cbd5 Author: Kyle Machulis <kylenonpolynomial.com> Desc: Bug 969950 - Cleaning up distribution sample ======== https://hg.mozilla.org/integration/gaia-central/rev/de97a5d865ef Author: Kyle Machulis <kylenonpolynomial.com> Desc: Bug 969650 - Subtree merge of yurenju/gaia-distribution-sample ======== https://hg.mozilla.org/integration/gaia-central/rev/eb9ae9a4503f Author: Yuren Ju <yurenjugmail.com> Desc: Merge pull request #3 from jds2501/simbookmarks Update SIM bookmark customization to include sample mcc mnc US SIM customization, r=yurenju ======== https://hg.mozilla.org/integration/gaia-central/rev/705efd9c2fcd Author: jds2501 <jsmithmozilla.com> Desc: Update SIM bookmark customization to include sample mcc mnc US SIM customization ======== https://hg.mozilla.org/integration/gaia-central/rev/72e64b8de4b1 Author: Yuren Ju <yurenjugmail.com> Desc: Merge pull request #2 from KevinGrandon/master Add calendar.json r=yurenju ======== https://hg.mozilla.org/integration/gaia-central/rev/56feb8a57eb1 Author: Kevin Grandon <kevingrandonyahoo.com> Desc: Add calendar.json ======== https://hg.mozilla.org/integration/gaia-central/rev/90aef8c4de58 Author: gasolin <gasolingmail.com> Desc: Create README.md ======== https://hg.mozilla.org/integration/gaia-central/rev/8f96ae99b519 Author: Yuren Ju <yurenjugmail.com> Desc: Merge pull request #1 from gasolin/patch-1 add runtime customize for bookmark setting, r=yurenju ======== https://hg.mozilla.org/integration/gaia-central/rev/80285b122244 Author: gasolin <gasolingmail.com> Desc: add runtime customize for bookmark setting ======== https://hg.mozilla.org/integration/gaia-central/rev/4e64191b5493 Author: Yuren Ju <yurenjugmail.com> Desc: Initial commit UltraBlame original commit: 5b5c102a852fc77dd3723965763f1a233308d3cb
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
…Log.jsm; r=gps,rnewman UltraBlame original commit: ea70694f55c81a214f6208a79700c69f496057c6
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
…ewrite to Task.jsm; r=unfocused UltraBlame original commit: 1d9b6d754b9dce17d25991d3f19465bf78f15fd2
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
…ent, r=rnewman UltraBlame original commit: 6399ede3f82f307b3d50b903ee4717c0f5e2205a
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
======== https://hg.mozilla.org/integration/gaia-central/rev/b55d2780462e Author: Etienne Segonzac <etiennesegonzac.info> Desc: Merge pull request #19261 from etiennesegonzac/bug-986062-edge-reflow-take-2 Bug 986062 edge reflow take 2 r=vingtetun,janx ======== https://hg.mozilla.org/integration/gaia-central/rev/6f5cf42576b3 Author: Etienne Segonzac <etiennesegonzac.info> Desc: Bug 986062 - Adding an integration test making sure we don't reflow during edge gestures. Take #2. ======== https://hg.mozilla.org/integration/gaia-central/rev/6dec66e2f9eb Author: Arnau <arnauarnaumarch.com> Desc: Merge pull request #19322 from pacorampas/replace-images-dialer-1010129 Bug 1010129 - [Dialer] Replace outdated icons and add missing ones. r=rik ======== https://hg.mozilla.org/integration/gaia-central/rev/c5bf4db8dc3d Author: Paco Rampas <pacorampasgmail.com> Desc: Bug 1010129 - [Dialer] Replace outdated icons and add missing ones. UltraBlame original commit: 32b3748d8fb065101feffb83d937e4965fc0a790
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
…kyfriedtakahe UltraBlame original commit: 27328268f50a0d1af094e0592892e9880972c813
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
… 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 #1: AdjustAppendParentForAfterContent [layout/base/nsCSSFrameConstructor.cpp:6059] #2: nsCSSFrameConstructor::ContentAppended(nsIContent*, nsIContent*, bool) [layout/base/nsCSSFrameConstructor.cpp:7155] #03: PresShell::ContentAppended(nsIDocument*, nsIContent*, nsIContent*, int) [layout/base/nsPresShell.cpp:4520] #04: nsNodeUtils::ContentAppended(nsIContent*, nsIContent*, int) [dom/base/nsNodeUtils.cpp:132] #05: nsINode::doInsertChildAt(nsIContent*, unsigned int, bool, nsAttrAndChildArray&) [dom/base/nsINode.cpp:1544] #06: nsINode::ReplaceOrInsertBefore(bool, nsINode*, nsINode*, mozilla::ErrorResult&) [dom/base/nsINode.cpp:2209] #07: mozilla::dom::NodeBinding::appendChild [obj-firefox/dom/bindings/NodeBinding.cpp:600] UltraBlame original commit: 98e34be1fb44344c1173d9d3c981b3e5a2da4762
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
…function-decl that happens to provide inline impl, in FakeInputPortService.cpp. rs=froydnj UltraBlame original commit: 740071f22e8901404f8e724ac25f40ae36ef9c20
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2019
…ical
Otherwise we can get a crash with the following stack:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 14711]
0x5d99974e in mozilla::gl::GLContext::BeforeGLCall (this=0x6dbf0800,
funcName=0x60f251a4 <mozilla::gl::GLContext::raw_fDeleteProgram(unsigned int)::__PRETTY_FUNCTION__> "void mozilla::gl::GLContext::raw_fDeleteProgram(GLuint)") at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:683
683 MOZ_ASSERT(IsCurrent());
(gdb) where
#0 0x5d99974e in mozilla::gl::GLContext::BeforeGLCall (this=0x6dbf0800,
funcName=0x60f251a4 <mozilla::gl::GLContext::raw_fDeleteProgram(unsigned int)::__PRETTY_FUNCTION__> "void mozilla::gl::GLContext::raw_fDeleteProgram(GLuint)") at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:683
#1 0x5d99bed6 in mozilla::gl::GLContext::raw_fDeleteProgram (this=0x6dbf0800, program=210003)
at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:2232
#2 0x5d99c10a in mozilla::gl::GLContext::fDeleteProgram (this=0x6dbf0800, program=210003)
at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:2270
#3 0x5daa0ae6 in mozilla::layers::ShaderProgramOGL::~ShaderProgramOGL (this=0x6d7df000, __in_chrg=<optimized out>)
at /home/roc/mozilla-inbound/gfx/layers/opengl/OGLShaderProgram.cpp:491
#4 0x5da86bdc in mozilla::layers::CompositorOGL::CleanupResources (this=0x67ae4d70)
at /home/roc/mozilla-inbound/gfx/layers/opengl/CompositorOGL.cpp:177
UltraBlame original commit: b745c996a71d8c56d12e04bdcaa7a508c3940a5c
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 30, 2019
======== https://hg.mozilla.org/integration/gaia-central/rev/20db0a074a97 Author: Johan Lorenzo <jlorenzomozilla.com> Desc: Merge pull request #31611 from JohanLorenzo/bug-1196717 Bug 1196717 - Dogfood test - Delete thread in SMS ======== https://hg.mozilla.org/integration/gaia-central/rev/9c3c875eb3a7 Author: Johan Lorenzo <jlorenzomozilla.com> Desc: Bug 1196717 - Dogfood test - Delete thread in SMS ======== https://hg.mozilla.org/integration/gaia-central/rev/e9b47d1d18c0 Author: Etienne Segonzac <etiennesegonzac.info> Desc: Merge pull request #31737 from etiennesegonzac/bug-1197738 Bug 1197738 - Take #2, fixing the menu transition without breaking the js engine r=albertopq ======== https://hg.mozilla.org/integration/gaia-central/rev/73e651d429c3 Author: Etienne Segonzac <etiennesegonzac.info> Desc: Bug 1197738 - Take #2, fixing the menu transition without breaking the js engine ======== https://hg.mozilla.org/integration/gaia-central/rev/dceba3fb6595 Author: Johan Lorenzo <jlorenzomozilla.com> Desc: Merge pull request #31675 from JohanLorenzo/bug-1184511 Bug 1184511 - [Aries] test_settings_device_info fails because only 1 … ======== https://hg.mozilla.org/integration/gaia-central/rev/99ebb8a2a579 Author: Johan Lorenzo <jlorenzomozilla.com> Desc: Bug 1184511 - [Aries] test_settings_device_info fails because only 1 IMEI is displayed UltraBlame original commit: c837e4315c69d713a691b1a067d4a80b277ab692
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 30, 2019
======== https://hg.mozilla.org/integration/gaia-central/rev/670bb87fcd72 Author: Johan Lorenzo <jlorenzomozilla.com> Desc: Merge pull request #33605 from JohanLorenzo/bug-1230099 Bug 1230099 - Delete tests already ported to Gij - round #2 ======== https://hg.mozilla.org/integration/gaia-central/rev/437631e3f8f6 Author: Johan Lorenzo <jlorenzomozilla.com> Desc: Bug 1230099 - Delete tests already ported to Gij - round #2 UltraBlame original commit: e9247c78bf3c449bacd517fd9ca9f4675f568e67
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 30, 2019
Modify the devtools autocomplete-popup to rely on a HTMLTooltip instance instead of a XUL panel. Other than the straightforward migration to HTML, the main difference with the new implementation is that the richlistbox has now been replace with a simple HTML list element. The former XUL widget used to be able to take the focus from the input it was linked to. This is no longer the case. Most autocomplete users were always keeping the focus in the input, except for the inspector-search, which was moving the focus back and forth between the input and the autocomplete's richlistbox. Now the focus is always in the input. A practical example to illustrate how this changes the UX: before when the user had the focus on the first element of the list, pressing "DOWN" would keep the element selected but visually move the focus in the input. Now the selection simply cycles to the next item. Even though this introduces a difference in behaviour compared to the previous implementation, it makes the inspector search UX consistent with the other autocomplete widgets used in devtools. Another difference is about the display for the inspector-search. The position of the autocomplete popup used to be above the input. This is now impossible to achieve because the search input is at the top of the toolbox and the HTML tooltip can not exceed the limits of the toolbox. For this #2 issue, either we manage to use XUL panel wrappers, in which case, the autocomplete will be displayed as it used to. Or we can invert the order in which items are inserted and explicitly ask for the autocomplete to be displayed below the input. I prefered not to change this here in order to make the code change easier to understand, but it should be addressed in a follow-up. MozReview-Commit-ID: jH9aXm9Jvz UltraBlame original commit: 548c72c399ec240c98d59f34a74ffe06664ec561
gecko-dev-updater
pushed a commit
that referenced
this pull request
Oct 4, 2019
Some background information on this change: DocShell loads about:blank when first starting up. This initial load can be avoided by setting `nodefaultsrc` on the browser element, but this will still cause some load events related to `about:blank` to fire anyway, as they are specified in the DOM spec (see e.g. bz's Comment #2 Bug 1447406). In particular `onSecurityChange` and `onLocationChange` are still fired, `onPageStart` and onPageStop` are not. These messages are unreliable and sometimes do not fire, to unrestand why it's helpful to look at a timeline of the events when starting up a GeckoSession. page about:blank --------------------------------------------------------- nsDocShell --- startup --- onPageStart --- onLocationChange --- onPageStop ----- busyState idle ---------- busy ------------------------------------------ idle- ^ ^ ^ ^ ^ geckoview.js (0) (1) (2) (3) (4) geckoview.js loads in parallel with nsDocShell startup process (and loading of about:blank). This means that consumers of GeckoView might start receiving navigation events at any of the points marked with (0) - (4). E.g. if geckoview starts up at (4) a consumer waiting for onPageStop for `about:blank` will actually wait forever (this is what happens before this change for our tests). As it can be seen there's not really a way to detect in which of the (0) - (4) state DocShell is when starting up geckoview.js. Checking for the busy state is not enough as an `idle` busy state might mean that we're in (0) or (4). Furthermore a consumer of geckoview has no way to know which onPageStop messages to wait for after an initial loadUri as e.g. the following is what would happen if geckoview.js happens to startup at (3): - loadUri(hello.html) - onPageStop (for about:blank) - onLoadRequest (for hello.html) which confuses any code that just waits for onPageStop. Desktop deals with this in `TabProgressListener.onStateChange` where the initial `about:blank` navigation is ignored and fake events are triggered at a convenient time. To patch implements a very similar behavior for geckoview, we ignore the initial `about:blank` `onLoadRequest` call, set `nodefaultsrc` so `onPageStart` and `onPageStop` events don't fire and fire the above calls when the `GeckoViewProgress` module has finished loading. This makes `about:blank` events deterministic with the exception of reloading an empty `GeckoSession`, which will often not fire any extra events. To account for that we load a dummy html page before the tests that used to rely on this behavior (which would actually fail occasionally due to the startup race condition explained above). This makes the tests pass reliably on x86_64 (20/20 runs passed in try). Differential Revision: https://phabricator.services.mozilla.com/D32586 UltraBlame original commit: cabf177300f4f47eddb7c7ae9b5113faf7cb1109
gecko-dev-updater
pushed a commit
that referenced
this pull request
Oct 4, 2019
…localhost., a=testonly Automatic update from web-platform-tests Cookie Store API: Fix crashes on http://localhost. Issue #1: The "SecureContext" IDL attribute considers localhost to be secure, but the Cookie Store API assumed that it would only be exposed on cryptographically secure origins, so a DCHECK caused attempts to set/delete cookies on http://localhost to crash. This CL replaces the DCHECK with an exception that is thrown on attempts to set/delete secure cookies on cryptographically insecure origins. Issue #2: The "secure" cookie attribute defaulted to true. Setting/deleting a secure cookie on a cryptographically insecure origin is prohibited. The cookieStore.delete() API excluded the option to set the "secure" attribute, however, so there was no way to delete an insecure cookie. This CL defaults the "secure" attribute to true on cryptographically secure origins, and false otherwise. Bug: 956641 Change-Id: Iff7c22713e8604d60b68d42199a74b2d08235712 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1700357 Commit-Queue: Staphany Park <staphanychromium.org> Reviewed-by: Victor Costan <pwnallchromium.org> Cr-Commit-Position: refs/heads/master{#681054} -- wpt-commits: 2e135c03ff73a7102011f4e610dc7890eb4332a1 wpt-pr: 17988 UltraBlame original commit: cb02577a9d4b821c86d81196c4d2a2181f1cc751
gecko-dev-updater
pushed a commit
that referenced
this pull request
Oct 4, 2019
…after overflow recalc, a=testonly
Automatic update from web-platform-tests
[Layout] bugfix: Update scrollable area after overflow recalc
Bug is:
<container overflow:scroll>
<target transform:scale(1)>
Initially, container's scrollbars are disabled.
When target changes its scale and grows outside of container,
scrollbars were not updated.
Fix #1 is to call UpdateScrollbarEnabledState. This resulted in
scrollbars being painted, but not clickable.
Fix #2, calling UpdateScrollableAreaSet makes scrollbars
clickable too.
Fix #2 was an educated guess.
Bug: 926167
Change-Id: I02454047c87aaecede9c56db1c02bbd1b21b15c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1704218
Commit-Queue: Aleks Totic <atoticchromium.org>
Reviewed-by: Stefan Zager <szagerchromium.org>
Cr-Commit-Position: refs/heads/master{#681091}
--
wpt-commits: a00fc0867640cf60333bc8831fad1170881e67d7
wpt-pr: 17868
UltraBlame original commit: ced9dbc351f58d3d24d3ef4461ed269817839b4f
gecko-dev-updater
pushed a commit
that referenced
this pull request
Oct 4, 2019
…ode for the updated binding API. r=julienw The repo has seen three notable changes since last time: - The pdb changes from PR #2, which don't really affect any outward behavior. - I updated the version of wasm-bindgen. - I created a WasmMemBuffer abstraction which lets us avoid the buffer copy without relying on wasm-bindgen implementation details. This is possible due to the new Uint8Array::view API that wasm-bindgen shipped in April. The last part is what allowed me to simplify the code in ProfilerGetSymbols-worker.js. Those changes are the only part that's worth reviewing. The changes in profiler_get_symbols.js are not worth reviewing; they're autogenerated by wasm-bindgen. The new version of wasm-bindgen generates slightly different JS code, and the addition of the WasmMemBuffer struct also caused some of that JS code to change. Differential Revision: https://phabricator.services.mozilla.com/D37130 UltraBlame original commit: e5a6e4d16569a34a52b478fc444939ad0961271d
gecko-dev-updater
pushed a commit
that referenced
this pull request
Oct 4, 2019
…stcase #2) to the WPT innerText getter test. r=mats Depends on D45159 Differential Revision: https://phabricator.services.mozilla.com/D46186 UltraBlame original commit: 4dc6ff8d58b31c747e519abcbe01270d01d66636
gecko-dev-updater
pushed a commit
that referenced
this pull request
Nov 4, 2019
`TextControlState::SetValue()` does 4 things. 1. Committing composition if there is and if possible. 2. Setting value with `TextEditor` if text editor and frame are available. 3. Setting value without `TextEditor` otherwise. 4. Notifying value changed. We can split #2 and #3 from it now because `AutoTextControlHandlingState` manages nested actions. Therefore, this patch creates `SetValueWithTextEditor()` and `SetValueWithoutTextEditor()` which take `AutoTextControlHandlingState`. Depends on D51394 Differential Revision: https://phabricator.services.mozilla.com/D51395 UltraBlame original commit: 7754b00fcfc82f9c98eafd780b90de4b4fc7cc1c
gecko-dev-updater
pushed a commit
that referenced
this pull request
Nov 30, 2019
…hen there's an override container height, a=testonly
Automatic update from web-platform-tests
[css-flexbox] Don't cache definiteness when there's an override container height
See stack trace below. We set the override container logical height to -1
for the initial layout of a flex item so that we compute the correct size
for min-height. However, that messes with our cache for definite heights
because we would always set it to indefinite in such a case.
Instead, just don't cache these values. That way we will later compute the right
thing for resolving flex-basis, etc.
(FlexNG can't come soon enough...)
#0 blink::LayoutBox::ContainingBlockLogicalHeightForPercentageResolution (this=0x3dda8d434198,
out_cb=0x7f6e7d42d8c0, out_skipped_auto_height_containing_block=0x0)
at ../../third_party/blink/renderer/core/layout/layout_box.cc:3833
#1 0x00007f6ee84ad0a1 in blink::LayoutFlexibleBox::MainAxisLengthIsDefinite (this=0x3dda8d434010,
child=..., flex_basis=Length(0%, Percent), add_to_cb=false)
at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:762
#2 0x00007f6ee84af930 in blink::LayoutFlexibleBox::MainSizeIsDefiniteForPercentageResolution (
this=0x3dda8d434010, child=...)
at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1125
#3 0x00007f6ee84ad7f5 in blink::LayoutFlexibleBox::UseOverrideLogicalHeightForPerentageResolution (
this=0x3dda8d434010, child=...)
at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1137
#4 0x00007f6ee83f2b9d in blink::LayoutBlock::AvailableLogicalHeightForPercentageComputation (
this=0x3dda8d434198) at ../../third_party/blink/renderer/core/layout/layout_block.cc:2333
#5 0x00007f6ee845e745 in blink::LayoutBox::ContainingBlockLogicalHeightForPercentageResolution (
this=0x3dda8d4243d0, out_cb=0x0, out_skipped_auto_height_containing_block=0x0)
at ../../third_party/blink/renderer/core/layout/layout_box.cc:3830
#6 0x00007f6ee86dcc5c in blink::LayoutBoxUtils::AvailableLogicalHeight (box=..., cb=0x3dda8d434198)
at ../../third_party/blink/renderer/core/layout/ng/layout_box_utils.cc:64
#7 0x00007f6ee86eafea in blink::LayoutNGMixin<blink::LayoutBlockFlow>::ComputeIntrinsicLogicalWidths (
this=0x3dda8d4243d0, min_logical_width=0px, max_logical_width=0px)
at ../../third_party/blink/renderer/core/layout/ng/layout_ng_mixin.cc:48
#8 0x00007f6ee83ef53a in blink::LayoutBlock::ComputePreferredLogicalWidths (this=0x3dda8d4243d0)
at ../../third_party/blink/renderer/core/layout/layout_block.cc:1509
#9 0x00007f6ee8451f01 in blink::LayoutBox::MaxPreferredLogicalWidth (this=0x3dda8d4243d0)
at ../../third_party/blink/renderer/core/layout/layout_box.cc:1395
#10 0x00007f6ee84adba2 in blink::LayoutFlexibleBox::ComputeInnerFlexBaseSizeForChild (this=0x3dda8d434198,
child=..., main_axis_border_and_padding=0px, child_layout_type=blink::LayoutFlexibleBox::kForceLayout)
at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:890
#11 0x00007f6ee84ae5d1 in blink::LayoutFlexibleBox::ConstructAndAppendFlexItem (this=0x3dda8d434198,
algorithm=0x7f6e7d42ed70, child=..., layout_type=blink::LayoutFlexibleBox::kForceLayout)
at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1203
#12 0x00007f6ee84aa27b in blink::LayoutFlexibleBox::LayoutFlexItems (this=0x3dda8d434198,
relayout_children=true, layout_scope=...)
at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:934
#13 0x00007f6ee84a9cff in blink::LayoutFlexibleBox::UpdateBlockLayout (this=0x3dda8d434198,
relayout_children=true) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:369
Bug: 1019138
Change-Id: Ie94e69a5f3fe6accc3623d358315b174088d5597
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1902514
Commit-Queue: David Grogan <dgroganchromium.org>
Auto-Submit: Christian Biesinger <cbiesingerchromium.org>
Reviewed-by: David Grogan <dgroganchromium.org>
Cr-Commit-Position: refs/heads/master{#713296}
--
wpt-commits: 8642cbbba24a10e8a34b4a2720062261f29be5dd
wpt-pr: 20137
UltraBlame original commit: bc2d69b245a2ed6eeeaadab6dcbc852f0c78eb3c
gecko-dev-updater
pushed a commit
that referenced
this pull request
Jan 28, 2020
…pipe_. r=froydnj It's no longer safe to try closing client_pipe_ when the I/O thread is woken up with data from the child process, because that can race with the launch thread doing its own close, and it's also unnecessary because of that other close. See also bug 1607153 comment #2. Differential Revision: https://phabricator.services.mozilla.com/D60627 UltraBlame original commit: ba74f99ce9bc43645be8ce58259497d16e7d12aa
gecko-dev-updater
pushed a commit
that referenced
this pull request
Jan 29, 2020
…pipe_. r=froydnj It's no longer safe to try closing client_pipe_ when the I/O thread is woken up with data from the child process, because that can race with the launch thread doing its own close, and it's also unnecessary because of that other close. See also bug 1607153 comment #2. Differential Revision: https://phabricator.services.mozilla.com/D60627 UltraBlame original commit: 7cc7a95fbad07486b87d21ccd1425847cdd1b82d
gecko-dev-updater
pushed a commit
that referenced
this pull request
Feb 27, 2020
…r=m_kato Its result has 4 meanings: 1. an editable block element for container of `mScanStartPoint`. 2. a topmost inline editable content for container of `mScanStartPoint` if there is no editable block parent. 3. container of `mScanStartPoint` if it's a block (either editable or non-editable). 4. container of `mScanStartPoint` if its parent is not editable and a inline content. #1, #2 and editable case of #3 make sense because the results are topmost editable content in current context. On the other hand, non-editable case of #3 and #4 are caused by unexpected wrong fallback code. So, let's make it always returns the content in the former meaning and if the caller needs the latter one, they should use the container by themselves. Therefore, for making what's the start of the search, this patch also makes new method take start content instead of hiding `mScanStartPoint` from the callers. Differential Revision: https://phabricator.services.mozilla.com/D63610 UltraBlame original commit: f8505320d2165dd86f8fbb212ffe87397a814aaf
gecko-dev-updater
pushed a commit
that referenced
this pull request
Mar 6, 2020
…spondWithMinimalUI() #2, a=testonly Automatic update from web-platform-tests [Payment Handler] CanMakePaymentEvent.respondWithMinimalUI() #2 Patch #2: Parsing and validating the parameters of CanMakePaymentEvent.respondWithMinimalUI() in Blink. The respondWithMinimalUI() method is disabled by default and can be enabled via chrome://flags/#enable-experimental-web-platform-features. Explainer: https://gist.github.com/rsolomakhin/eba91c185028899883d2c7f37f357d7c Demo: https://rsolomakhin.github.io/pr/apps/micro/ Test: wpt/payment-handler/respond-with-minimal-ui.https.html Chrome feature status: https://chromestatus.com/feature/5661524146257920 Blink-dev intent to prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/kTLpgFJz6Ck/IQeiGDtOAwAJ Bug: 1005076 Change-Id: I1573cef83d357046144d198e870c7f3fd54fd976 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2072582 Reviewed-by: Danyao Wang <danyaochromium.org> Commit-Queue: Rouslan Solomakhin <rouslanchromium.org> Cr-Commit-Position: refs/heads/master{#745010} -- wpt-commits: abc2ed2227ce574b659dfdbeed524bdb0decf4ec wpt-pr: 21966 UltraBlame original commit: ded8c5a9f1433ed4ce889fa37630b50e83fe886a
gecko-dev-updater
pushed a commit
that referenced
this pull request
Mar 13, 2020
Now that `fix_stacks.py` is being used instead of `fix_macosx_stack.py`, stack-fixing time has dropped from about 14 minutes to about 30 seconds on my new MacBook Pro. Also, print a warning about stacks not being fixed if `MOZ_DISABLE_STACK_FIX` is set. This warning shows up at the start of the test run. Also, print a warning about stack fixing slowness, because 30 seconds is long enough to possibly be surprising. This warning shows up just before the first stack frame is fixed, like this: ``` Assertion failure: false (BEEP BOOP), at /home/njn/moz/au3/dom/base/nsGlobalWindowOuter.cpp:1342 Initializing stack-fixing for the first stack frame, this may take a while... #1: nsGlobalWindowOuter::nsGlobalWindowOuter(unsigned long) (/home/njn/moz/au3/dom/base/nsGlobalWindowOuter.cpp:1342) #2: ... ``` Differential Revision: https://phabricator.services.mozilla.com/D65676 UltraBlame original commit: 9d6c366e7cde369c65ddb85b258dbacbf396e65e
gecko-dev-updater
pushed a commit
that referenced
this pull request
Apr 25, 2020
…modified with setKeyframes, a=testonly Automatic update from web-platform-tests Base style should respond to animations modified with setKeyframes When animating font-affecting properties (e.g. font-size) while the base style contains font-relative units (e.g. em), we can not use the base computed style optimization, since the font-relative units in the base must respond to the font animation. A has_font_affecting_animation_ flag was recently added to ElementAnimations to assist in disabling the optimization under these circumstances. However, that was added with an insufficient understanding of ElementAnimation's lifetime, and hence this flag doesn't really work properly. For example, if we have an animation that initially doesn't affect the font, but then suddenly affects the font after all via setKeyframes, we would paint one incorrect frame before discovering that the font is now affected, and then (for frame #2 and subsequent) we'd be able to disable the optimization. This CL instead checks if the EffectStack affects the font when we're considering the base computed style for use. Bug: 437689 Change-Id: If07f1e82559673433be0a80d2c3edea1c1a5165a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2139662 Reviewed-by: Robert Flack <flackrchromium.org> Commit-Queue: Anders Hartvoll Ruud <andruudchromium.org> Cr-Commit-Position: refs/heads/master{#759197} -- wpt-commits: f16078c799c17f920a1328347f99588b10dfea5f wpt-pr: 22914 UltraBlame original commit: 177205e7798f54637696aa452bfc9588c7312699
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 16, 2020
…efs that could affect font inflation change. r=kats When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert ``` ###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677 #1: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148] #2: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177] #03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504] #04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557] #05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340] #06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115] #07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297] #08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650] #09: 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 UltraBlame original commit: 6698b842822e238196b46001e4d4770bb8781bec
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 16, 2020
The test fixes all fell into the follow categories: A) The test uses requestAnimationFrame to wait one frame and expects scrolling to be complete. With the desktop zooming scrollbars in order for the scrolling to show up on the main thread we need to send the scroll request to the compositor and then hear back from it via an apz repaint request (apz callback helper). Waiting on requestAnimationFrame will complete the first part, but not necessarily the second part. The fix is to wait for a scroll event. B) Switching tests to wait for scroll events exposes another problem: the test can do things that cause a scroll in order to setup the test (and that may not be obvious that it causes a scroll) before actually proceeding to do the test and do something that causes a scroll and then checks for the scroll change of the second thing. Waiting for a requestAnimationFrame would include both those scrolls without desktop zooming scrollbars, but if we wait for a scroll event we will get the scroll event for the first thing which we are not interested in. So we need to make sure scroll events are cleared out before waiting for any scroll events. We do this by waiting two requestAnimationFrame's and waiting for apz to be flushed. We also use this when a test does something and it wants to test that scrolling is not performed. The main thing that causes scrolling that may not be obvious: calling node.focus(). With stacks like: from test_scroll_per_page.html ``` #1: 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] #03: mozilla::layout::ScrollAnchorContainer::ApplyAdjustments() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4742913] #04: mozilla::PresShell::FlushPendingScrollAnchorAdjustments() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4650069] #05: mozilla::PresShell::ProcessReflowCommands(bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x465742b] #06: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4656af8] #07: mozilla::dom::Document::FlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1a87d3c] #08: 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] #09: 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 ``` #1: 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] #03: 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] #04: mozilla::PresShell::DoScrollContentIntoView() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4653776] #05: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4656b11] #06: mozilla::dom::Document::FlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1a87d3c] #07: 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] #08: nsFocusManager::ScrollIntoView(mozilla::PresShell*, nsIContent*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1bedd1c] #09: 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 UltraBlame original commit: 30cd33572b3d5c4bfa8e5883396dc3aa84a62e0b
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 16, 2020
…efs that could affect font inflation change. r=kats When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert ``` ###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677 #1: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148] #2: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177] #03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504] #04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557] #05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340] #06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115] #07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297] #08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650] #09: 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 UltraBlame original commit: 57470917615238e6a9a0ab2648e6b607ad8064de
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 16, 2020
…efs that could affect font inflation change. r=kats When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert ``` ###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677 #1: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148] #2: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177] #03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504] #04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557] #05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340] #06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115] #07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297] #08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650] #09: 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 UltraBlame original commit: cb92660b87e5a63ed15e7c2f6b47f03a549d82c6
gecko-dev-updater
pushed a commit
that referenced
this pull request
Dec 3, 2020
…D TREE For the same reason as dump-syms. Differential Revision: https://phabricator.services.mozilla.com/D98553 UltraBlame original commit: 2c61fdd0277b7ebb43c25258b92397308bbfdcca
gecko-dev-updater
pushed a commit
that referenced
this pull request
May 16, 2023
We already cherry-picked this when we vendored 218b56e516. Upstream commit: https://webrtc.googlesource.com/src/+/cb954cdb0814e2119b6cb0fe2512d532b5c1419c 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 <alcooperchromium.org> Reviewed-by: Mark Foltz <mfoltzchromium.org> Commit-Queue: Mark Foltz <mfoltzchromium.org> Commit-Queue: Alexander Cooper <alcooperchromium.org> Cr-Original-Commit-Position: refs/heads/main{#39275} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293243 Bot-Commit: rubber-stamperappspot.gserviceaccount.com <rubber-stamperappspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5563{#2} Cr-Branched-From: 6c032cb8356b0d3f717c4fcf50796241f2bba6c2-refs/heads/main{#39207} UltraBlame original commit: 45b351bdf4eab3c736d0f23aff36e2a09ef036f5
gecko-dev-updater
pushed a commit
that referenced
this pull request
Jun 16, 2023
…e DOM tree in each time of the loop r=m_kato There are 2 possible scenarios which are not handled by the method. 1. Moving content node to new `<blockquote>` has already been moved to outside of the editing host. 2. There is no container to insert new `<blockquote>`, e.g., in an inline editing host. In the case #1, we should ignore the ex-child node. In the case #2, we should abort it. Note that Chrome inserts `<blockquote>` even if there is no proper container. However, such behavior is disagreed in interop-2023. Therefore, it's okay just to abort it for now. Depends on D180781 Differential Revision: https://phabricator.services.mozilla.com/D180782 UltraBlame original commit: 42f3f3ab11b47f1d56d8bcd6a128398539dd1f23
gecko-dev-updater
pushed a commit
that referenced
this pull request
Sep 29, 2023
…g anchor element's siblings, a=testonly
Automatic update from web-platform-tests
Fix :has() invalidation bug when removing anchor element's siblings
This CL fixes a :has() invalidation bug when the following conditions
are met:
1. A style rule uses a :has() pseudo class. The :has() test result is
affected by the anchor element's relationship to its sibling
element at fixed distance. (e.g. '.a:has(+ .b) {}')
2. The :has() pseudo class was tested on an anchor element and it
didn't matched.
3. If a sibling of the anchor element is removed, the :has() will
match the anchor element.
(e.g. '<div class=a></div><div id=target></div><div class=b></div>')
4. Remove a sibling of the anchor element so that the :has() matches
the anchor element. (e.g. 'target.remove();')
For the removal, StyleEngine have to schedule :has() invalidation
even if the removed element doesn't have any identifier stored in
RuleFeatureSet. But it is not efficient to schedule :has()
invalidation for every element removal.
To avoid unnecessary :has() invalidation, StyleEngine checks whether
its parent has the 'ChildrenAffectedByDirectAdjacentRules' flag set
or not.
Currently, the SelectorChecker sets the flag only when it consumes
a direct adjacent combinator(+). This works most cases but it doesn't
work in this case (condition #2) because the SelectorChecker stops
the :has() argument selector matching before consuming the direct
adjacent combinator. Due to this, the parent of the anchor element
doesn't have the 'ChildrenAffectedByDirectAdjacentRules' flag set
and the StyleEngine doesn't schedule the :has() invalidation for the
removal.
To fix the error, when the SelectorChecker tests a :has() pseudo
class on an anchor element and the :has() is affected by the anchor
element's relationship to a sibling at fixed distance, the
SelectorChecker sets the flag of the parent to indicate that
StyleEngine need to schedule :has() invalidation whenever any child
of the element is removed.
Bug: 1480643
Change-Id: I5ec2e3c1db2773020368415f68bca1503367e669
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4864627
Commit-Queue: Byungwoo Lee <bleeigalia.com>
Reviewed-by: Rune Lillesveen <futharkchromium.org>
Cr-Commit-Position: refs/heads/main{#1198137}
--
wpt-commits: 2f5741f704e062180e3424c1126ba5b30cf6dd07
wpt-pr: 42012
UltraBlame original commit: 40167ce4199ae6f558a5f72fb273c30651d7477b
gecko-dev-updater
pushed a commit
that referenced
this pull request
Oct 30, 2023
We already cherry-picked this when we vendored 402f60c2ea. Upstream commit: https://webrtc.googlesource.com/src/+/70aa7e99e4af06e9a2273793179dfcfddad11898 [Merge to 117] CHECK against overwrites in send_modules_map_ (cherry picked from commit 9d8fb97b3ca56ec9920271d8e545ae2ac76b143c) No-try: true Bug: chromium:1477075 Change-Id: Ia05a868bfab9e99ef66704e8d6bce516a7a43b0a Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318440 Reviewed-by: Sergey Silkin <ssilkinwebrtc.org> Commit-Queue: Harald Alvestrand <htawebrtc.org> Cr-Original-Commit-Position: refs/heads/main{#40673} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/319100 Reviewed-by: Taylor Brandstetter <deadbeefwebrtc.org> Cr-Commit-Position: refs/branch-heads/5938{#2} Cr-Branched-From: 82e5f91a2bdf955aa870142008fbdc9ac12f6acd-refs/heads/main{#40524} UltraBlame original commit: a97de0478e3a356b65ddf73e90f074531bdaa6cf
gecko-dev-updater
pushed a commit
that referenced
this pull request
Nov 21, 2023
…chevobbe Just starting up a debug build you will get 40 copies of this printed. The uri that we fail to get host of is about:newtab. One stack looks like this #2: mozilla::BasePrincipal::GetIsLoopbackHost(bool*) #03: 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 #04: ShouldLoadCachedImage(imgRequest*, mozilla::dom::Document*, nsIPrincipal*, nsIContentPolicy::nsContentPolicyType, bool) #05: imgLoader::LoadImage(nsIURI*, nsIURI*, nsIReferrerInfo*, nsIPrincipal*, unsigned long long, nsILoadGroup*, imgINotificationObserver*, nsINode*, mozilla::dom::Document*, unsigned int, nsISupports*, nsIContentPolicy::nsContentPolicyType, nsTSubstring<char16 #06: nsContentUtils::LoadImage(nsIURI*, nsINode*, mozilla::dom::Document*, nsIPrincipal*, unsigned long long, nsIReferrerInfo*, imgINotificationObserver*, int, nsTSubstring<char16_t> const&, imgRequestProxy**, nsIContentPolicy::nsContentPolicyType, bool, bool, #07: mozilla::css::ImageLoader::LoadImage(mozilla::StyleComputedUrl const&, mozilla::dom::Document&) #08: mozilla::StyleComputedUrl::ResolveImage(mozilla::dom::Document&, mozilla::StyleComputedUrl const*) #09: 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 UltraBlame original commit: 32dfe20d5a1a30147d1a78169267835fbda15bb6
gecko-dev-updater
pushed a commit
that referenced
this pull request
Dec 21, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/52bc9f7c1205f4b731ea0289b059f7d240c1e228 [Merge M119] Return error when requested codec is preferred but not negotiated Because of our asymmetrical codec situation, it's possible to have send only codecs that we cannot negotiate even with ourselves. This means that we should not have a DCHECK, but just a plain error. (cherry picked from commit 1adea9806d7aec9b5f91181231ccc31fef3b115f) Bug: chromium:1442194, webrtc:15064 Change-Id: I0c170e5c7f356197bcb04bcecb8259c344423ccb Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323183 Reviewed-by: Harald Alvestrand <htawebrtc.org> Commit-Queue: Florent Castelli <orphiswebrtc.org> Cr-Original-Commit-Position: refs/heads/main{#40939} No-Try: True Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324044 Reviewed-by: Guido Urdaneta <guidouwebrtc.org> Cr-Commit-Position: refs/branch-heads/6045{#2} Cr-Branched-From: bce7ce7ba054ac0e79fed49b84ef52fb24c31778-refs/heads/main{#40854} UltraBlame original commit: d0c99a837418b71ed7b7fed2094737aaa0add2de
gecko-dev-updater
pushed a commit
that referenced
this pull request
Jan 25, 2024
…ect> / <embed> as subdocuments. r=longsonr These look like two really old bugs. Part of the issue is that <object> / <embed> manage their frame loader quite differently from <iframe>. This means that we may have a PresShell / ViewManager / etc for a frame loader that doesn't yet have a frame associated. For example, this is the viewport creation for the SVG document that reproduces the problem: #0 0x00005cc60e8302e7 in mozilla::ViewportFrame::SetViewInternal(nsView*) (this=0x68599020, aView=0x683d8f00) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/ViewportFrame.h:106 #1 0x00005cc60e842858 in nsIFrame::SetView(nsView*) (this=0x68599020, aView=0x683d8f00) at /home/emilio/src/moz/gecko/layout/generic/nsFrame.cpp:7057 #2 0x00005cc60e77258a in nsCSSFrameConstructor::ConstructRootFrame() (this=0xc72c715e00) at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:2424 #3 0x00005cc60e7342f5 in mozilla::PresShell::Initialize() (this=0x6830e000) at /home/emilio/src/moz/gecko/layout/base/PresShell.cpp:1758 #4 0x00005cc60c9fb02a in nsContentSink::StartLayout(bool) (this=<optimized out>, aIgnorePendingSheets=<optimized out>) at /home/emilio/src/moz/gecko/dom/base/nsContentSink.cpp:1160 #5 0x00005cc60e2c1581 in nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int, bool) (this=<optimized out>, aName=<optimized out>, aAtts=0x6fde8200, aAttsCount=<optimized out>, aLineNumber=3, aColumnNumber=<optimized out>, aInterruptable=true) at /home/emilio/src/moz/gecko/dom/xml/nsXMLContentSink.cpp:982 #6 0x00005cc60e2c17d7 in non-virtual thunk to nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int) () at /home/emilio/src/moz/gecko/dom/xml/nsXMLContentSink.cpp:889 #7 0x00005cc60c360307 in nsExpatDriver::HandleStartElement(void*, char16_t const*, char16_t const**) (aUserData=0x224f650d0cc0, aName=0x685aef20 u"http://www.w3.org/2000/svg\xffffdesc", aAtts=0x6fde8200) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:293 #8 0x00005cc60ee91cea in doContent (parser=0xc72c70f800, startTagLevel=0, enc=<optimized out>, s=<optimized out>, end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, nextPtr=0x7ffca2653288, haveMore=1 '\001') at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:2872 #9 0x00005cc60ee90059 in contentProcessor (parser=0xc72c70f800, start=0xffffffe6 <error: Cannot access memory at address 0xffffffe6>, end=0xc72c511360 "", endPtr=0x1) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:2528 #10 0x00005cc60ee8f8d5 in doProlog (parser=<optimized out>, enc=0x5cc612ce0930 <little2_encoding_ns>, s=0x5bbd31ab508e "<", end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, tok=<optimized out>, next=<optimized out>, nextPtr=0x7ffca2653288, haveMore=1 '\001', allowClosingDoctype=1 '\001') at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:4591 #11 0x00005cc60ee8d86e in prologProcessor (parser=0xc72c70f800, s=0x5bbd31ab5020 "<", end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, nextPtr=0x7ffca2653288) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:4311 #12 0x00005cc60ee8cf45 in MOZ_XML_Parse (parser=0xc72c70f800, s=0x5bbd31ab5020 "<", len=262144, isFinal=0) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:1894 #13 0x00005cc60c3627bc in nsExpatDriver::ParseBuffer(char16_t const*, unsigned int, bool, unsigned int*) (this=0x224f650d0cc0, aBuffer=0x5bbd31ab5020 u"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<svg height=\"2970\" width=\"2100\" viewBox=\"0 0 2100 2970\" version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlin"..., aLength=131072, aIsFinal=false, aConsumed=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:875 #14 0x00005cc60c362c91 in nsExpatDriver::ConsumeToken(nsScanner&, bool&) (this=<optimized out>, aScanner=..., aFlushTokens=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:970 #15 0x00005cc60c3666a8 in nsParser::Tokenize(bool) (this=0x224f65038e80, aIsFinalChunk=false) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:1410 #16 0x00005cc60c36595e in nsParser::ResumeParse(bool, bool, bool) (this=0x224f65038e80, allowIteration=true, aIsFinalChunk=false, aCanInterrupt=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:961 #17 0x00005cc60c366c86 in nsParser::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (this=0x224f65038e80, request=<optimized out>, pIStream=0x6fdfc430, sourceOffset=<optimized out>, aLength=131072) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:1317 #18 0x00005cc60c897cc2 in nsObjectLoadingContent::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (this=<optimized out>, aRequest=0x68483080, aInputStream=0x6fdfc430, aOffset=0, aCount=131072) at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:1055 #19 0x00005cc60b9d18f8 in mozilla::net::HttpChannelChild::DoOnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long, unsigned int) (this=0x68483000, aRequest=0x68483080, aContext=<optimized out>, aStream=0x6fdfc430, aOffset=0, aCount=743510880) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:968 #20 0x00005cc60b9d5cbf in mozilla::net::HttpChannelChild::OnTransportAndData(nsresult const&, nsresult const&, unsigned long const&, unsigned int const&, nsTString<char> const&) (this=0x68483000, aChannelStatus=<optimized out>, aTransportStatus=0x683be5bc: -2142568440, aOffset=<optimized out>, aCount=<optimized out>, aData=...) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:867 #21 0x00005cc60badb535 in mozilla::net::ChannelEventQueue::FlushQueue() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/netwerk/ipc/ChannelEventQueue.cpp:90 #22 0x00005cc60b976fda in mozilla::net::ChannelEventQueue::MaybeFlushQueue() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/net/ChannelEventQueue.h:350 #23 0x00005cc60baec442 in mozilla::net::ChannelEventQueue::CompleteResume() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/net/ChannelEventQueue.h:329 #24 mozilla::net::ChannelEventQueue::ResumeInternal()::CompleteResumeRunnable::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/ipc/ChannelEventQueue.cpp:148 #25 0x00005cc60b53d4f1 in mozilla::SchedulerGroup::Runnable::Run() (this=0x685b0200) at /home/emilio/src/moz/gecko/xpcom/threads/SchedulerGroup.cpp:282 #26 0x00005cc60b54ff80 in nsThread::ProcessNextEvent(bool, bool*) (this=0x3dd7f4f3020, aMayWait=<optimized out>, aResult=0x7ffca2653ea7) at /home/emilio/src/moz/gecko/xpcom/threads/nsThread.cpp:1220 #27 0x00005cc60b552f0d in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x68599020, aMayWait=true) at /home/emilio/src/moz/gecko/xpcom/threads/nsThreadUtils.cpp:481 The parent view may not be set properly if the frame is not current by the time it is created. For example in this case the parent for the root view is non-null and comes from the following MakeWindow call: #0 nsDocumentViewer::MakeWindow(nsSize const&, nsView*) (this=0xc72ca72cd0, aSize=..., aContainerView=0x683ba500) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:2368 #1 0x00005cc60e789b50 in nsDocumentViewer::InitInternal(nsIWidget*, nsISupports*, mozilla::dom::WindowGlobalChild*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, bool, bool, bool) (this=0xc72ca72cd0, aParentWidget=<optimized out>, aState=0x0, aActor=0x0, aBounds=..., aDoCreation=true, aNeedMakeCX=<optimized out>, aForceSetNewDocument=<optimized out>) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:933 #2 0x00005cc60e789959 in nsDocumentViewer::Init(nsIWidget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::dom::WindowGlobalChild*) (this=0xc72ca72cd0, aParentWidget=0x7ffca2651020, aBounds=..., aActor=0x7f6216725c00) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:762 #3 0x00005cc60f4f584f in nsDocShell::SetupNewViewer(nsIContentViewer*, mozilla::dom::WindowGlobalChild*) (this=0x684db000, aNewViewer=<optimized out>, aWindowActor=<optimized out>) at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:8017 #4 0x00005cc60f4f5204 in nsDocShell::Embed(nsIContentViewer*, mozilla::dom::WindowGlobalChild*) (this=0x684db000, aContentViewer=0x7ffca2651020, aWindowActor=0x683ba500) at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:5745 #5 0x00005cc60f4dbc7b in nsDocShell::CreateContentViewer(nsTSubstring<char> const&, nsIRequest*, nsIStreamListener**) (this=0x684db000, aContentType=..., aRequest=0x68483080, aContentHandler=<optimized out>) at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:7819 #6 0x00005cc60f4dab99 in nsDSURIContentListener::DoContent(nsTSubstring<char> const&, bool, nsIRequest*, nsIStreamListener**, bool*) (this=0x683056a0, aContentType=..., aIsContentPreferred=<optimized out>, aRequest=0x68483080, aContentHandler=0xc72c5e8608, aAbortProcess=0x7ffca265139f) at /home/emilio/src/moz/gecko/docshell/base/nsDSURIContentListener.cpp:181 #7 0x00005cc60c2fd8f5 in nsDocumentOpenInfo::TryContentListener(nsIURIContentListener*, nsIChannel*) (this=0xc72c5e85e0, aListener=0x683056a0, aChannel=<optimized out>) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:632 #8 0x00005cc60c2fccd1 in nsDocumentOpenInfo::DispatchContent(nsIRequest*, nsISupports*) (this=0xc72c5e85e0, request=0x68483080, aCtxt=<optimized out>) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:313 #9 0x00005cc60c2fc5aa in nsDocumentOpenInfo::OnStartRequest(nsIRequest*) (this=<optimized out>, request=0x68483080) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:191 #10 0x00005cc60c8975c4 in nsObjectLoadingContent::LoadObject(bool, bool, nsIRequest*) (this=0x4b1b3938b6a8, aNotify=<optimized out>, aForceLoad=<optimized out>, aLoadingChannel=0x68483080) at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:2218 #11 0x00005cc60c89681f in nsObjectLoadingContent::OnStartRequest(nsIRequest*) (this=0x4b1b3938b6a8, aRequest=0x68483080) at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:1006 #12 0x00005cc60b9d1020 in mozilla::net::HttpChannelChild::DoOnStartRequest(nsIRequest*, nsISupports*) (this=0x68483000, aRequest=0x68483080, aContext=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:708 #13 0x00005cc60b9d481b in mozilla::net::HttpChannelChild::OnStartRequest(nsresult const&, mozilla::net::nsHttpResponseHead const&, bool const&, mozilla::net::nsHttpHeaderArray const&, mozilla::net::ParentLoadInfoForwarderArgs const&, bool const&, bool const&, bool const&, unsigned long const&, int const&, unsigned int const&, nsTString<char> const&, nsTString<char> const&, mozilla::net::NetAddr const&, mozilla::net::NetAddr const&, unsigned int const&, nsTString<char> const&, long const&, bool const&, bool const&, bool const&, mozilla::net::ResourceTimingStructArgs const&, bool const&, mozilla::Maybe<unsigned int> const&, bool const&, nsILoadInfo::CrossOriginOpenerPolicy const&) However, even though aContainerView is non-null, the view is incorrect, it's the view for the _old_ frame. The view parent/child relationship gets cleared properly in: #1 0x00005cc60e8e82bf in BeginSwapDocShellsForViews (aSibling=0x0) at /home/emilio/src/moz/gecko/layout/generic/nsSubDocumentFrame.cpp:1027 warning: Source file is more recent than executable. #2 0x00005cc60e8e810b in nsSubDocumentFrame::DestroyFrom (this=0x6cd04eaa45a8, aDestructRoot=0x6cd04eaa45a8, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsSubDocumentFrame.cpp:943 #3 0x00005cc60e7b71a3 in nsIFrame::Destroy (this=0x6cd04eaa45a8) at /home/emilio/src/moz/gecko/layout/generic/nsIFrame.h:657 #4 0x00005cc60e80baac in nsBlockFrame::RemoveFrame (this=0x4b1b39362d88, aListID=<optimized out>, aOldFrame=0x6cd04eaa45a8) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:5597 #5 0x00005cc60e8df29f in nsPlaceholderFrame::DestroyFrom (this=0x4b1b39363240, aDestructRoot=0x4b1b39363240, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsPlaceholderFrame.cpp:181 #6 0x00005cc60e80cf19 in nsBlockFrame::DoRemoveFrameInternal (this=<optimized out>, aDeletedFrame=0x0, aFlags=<optimized out>, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:6265 #7 0x00005cc60e82d947 in nsBlockFrame::DoRemoveFrame (this=0x4b1b39362d88, aDeletedFrame=0x683d8f00, aFlags=244338087) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.h:528 #8 0x00005cc60e80ba3a in nsBlockFrame::RemoveFrame (this=0x4b1b39362d88, aListID=<optimized out>, aOldFrame=0x4b1b39363240) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:5581 #9 0x00005cc60e77fd5c in nsCSSFrameConstructor::ContentRemoved (this=<optimized out>, aChild=0x4b1b3938b600, aOldNextSibling=<optimized out>, aFlags=<optimized out>) at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:7583 #10 0x00005cc60e779a35 in nsCSSFrameConstructor::RecreateFramesForContent (this=0x6fdf9800, aContent=0x4b1b3938b600, aInsertionKind=nsCSSFrameConstructor::InsertionKind::Sync) at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:8593 #11 0x00005cc60e751745 in mozilla::RestyleManager::ProcessRestyledFrames (this=<optimized out>, aChangeList=...) at /home/emilio/src/moz/gecko/layout/base/RestyleManager.cpp:1484 But the temporary state is stored in the _old_ frame-loader, so when we create the new frame, we get to nsSubDocumentFrame::Init, and find nothing, and thus go through nsFrameLoader::Show. But we do have a pres-shell, and nsFrameLoader::Show just early-returns then, and thus we end up with a detached pres shell which is not hooked to the view tree and thus not painted... So there are multiple potential fixes. First (this is the approach this patch takes): * Make nsHideViewer not fail to hide a presentation when the frame loader has changed. This is not an issue per se, but leaves stale views / etc living for too long which is not nice. * Fix up the Show() code path to handle this case properly by parenting the pres-shell and initializing the docshell properly. Second potential fix would be to store the temporary state somewhere else than the frame loader (like the element). This may be a less invasive change somehow, but it looks pretty fishy to me, and not particularly better... Terribly sorry about the lack of test-case, but this is racy as crazy and I had a lot of trouble to even reproduce it in a debug build. This needs the PresShell creation for the subdocument to happen right after setting .data on the <object>, but before processing its reframe. Differential Revision: https://phabricator.services.mozilla.com/D69487 UltraBlame original commit: 50b298a5272a5c248c5f428cfb03087d919f0a7b
gecko-dev-updater
pushed a commit
that referenced
this pull request
Nov 1, 2024
…t/last formatted line., a=testonly Automatic update from web-platform-tests [text-box-trim] More spec-compliant first/last formatted line. See https://drafts.csswg.org/css-pseudo-4/#first-text-line 1. For a block container that establishes an inline formatting context, the "first formatted line" is its first line box, if it has one. Otherwise, there is no first formatted line. 2. Otherwise, for a block container that has block children, look inside the first in-flow block child (if any) and do #1 if it establishes an inline formatting context. Otherwise, do #2. In short, we don't need to search for line boxes in blocks after the first block child. If there is no line in the first child, there's no "first formatted line". There's no spec for "last formatted line", but apply the same logic. I.e. if the last block child has no line, there's no "last formatted line". This allows us to simplify things a bit, especially when it comes to re-laying out (kTextBoxTrimEndDidNotApply). The only case where we need this now is for blocks inside inlines: If the last formatted line is inside a block-in-inline, we need to go back and re-lay it out if it turns out to be the last line (which isn't something we can check inside block-in-inline layout). Note: When adding support for block fragmentation, trimming at a fragmentainer's block end will be another case where we need to re-lay out. The motivation for this change was text box trimming inside block fragmentation (upcoming CL), and be able to add support for that and still be reasonably confident that it won't become too complicated. This fixes one existing test. Some other existing tests had to be updated because of this change (they were making incorrect assumptions about first/last formatted line). As a result of that, some new refs had to be added, since other tests were piggy-backing on the same ref. Bug: 40254880, 367766472 Change-Id: I3fcc53af86353725b1f5705a5528493a72bf2e69 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5952979 Commit-Queue: Morten Stenshorne <mstenshochromium.org> Reviewed-by: Koji Ishii <kojiichromium.org> Cr-Commit-Position: refs/heads/main{#1373765} -- wpt-commits: 274bd0d593efebce81292bc6f9a8ca58c578e343 wpt-pr: 48815 UltraBlame original commit: bb11e616218b029dfcef932271989fe21370ee49
gecko-dev-updater
pushed a commit
that referenced
this pull request
Nov 1, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/28b793b4dd275bf2b901b87e01c0ee8d4f5732fc [Merge-130] Fix LibvpxVp9Encoder simulcast bug. As of [1], a single VP9 encoder instance can produce simulcast 4:2:1. When it does, the EncodedImage has its simulcast index set (0, 1, 2). The bug is that if you then go back to a single encoder instance, either because you're doing singlecast or because you're doing simulcast with scaling factors that are not power of two (not 4:2:1), then the simulcast index which was previously set to 2 is not reset due to the old code path never calling SetSimulcastIndex. Example repro: 1. Send VP9 simulcast {180p, 360p, 720p}, i.e. 4:2.1. 2. Reconfigure to {180p, 360p, 540p}, i.e. no longer 4:2:1. What should happen: all three layers are sent. What actually happened: 180p is not sent and the 540p layer flips flops between 180p and 540p because the EncodedImage says simulcast index is 2 for both encodings[0] and encodings[2]. The fix is a one-line change: `SetSimulcastIndex(std::nullopt)` in the case that we don't have a `simulcast_to_svc_converter_` that sets it (0, 1, 2) for us. [1] https://webrtc-review.googlesource.com/c/src/+/360280 (cherry picked from commit a6fbb35ac1849c5cd823ec90121d92fc5b776b35) Bug: chromium:370299916 Change-Id: I94ce1a0bde43ef56cba930cb69b744877bbd4bf9 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363941 Reviewed-by: Sergey Silkin <ssilkinwebrtc.org> Commit-Queue: Henrik Boström <hboswebrtc.org> Cr-Original-Commit-Position: refs/heads/main{#43109} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364302 Reviewed-by: Ilya Nikolaevskiy <ilnikwebrtc.org> Cr-Commit-Position: refs/branch-heads/6723{#2} Cr-Branched-From: 13e377b804f68aa9c20ea5e449666ea5248e3286-refs/heads/main{#43019} UltraBlame original commit: 037ce247fcd7f766043ca71f9edff73de111abd3
gecko-dev-updater
pushed a commit
that referenced
this pull request
Nov 27, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/4078ddf474ac38188866a282d611861d8fc34860 [Merge-131] Allow not specifying `requested_resolution` on inactive encodings. This fixes the bug where scaleResolutionDownTo must be specified even on inactive encodings (scaleResolutionDownTo is the JavaScript name for what is called requested_resolution inside WebRTC). (cherry picked from commit 1c262bf5a4c2f2aaf226b24f11195ba8cae772f1) Bug: chromium:375048792 Change-Id: I3206ef7de09eaba24a5b4305d888ec4904617e58 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366522 Auto-Submit: Henrik Boström <hboswebrtc.org> Commit-Queue: Ilya Nikolaevskiy <ilnikwebrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnikwebrtc.org> Commit-Queue: Henrik Boström <hboswebrtc.org> Cr-Original-Commit-Position: refs/heads/main{#43292} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366661 Cr-Commit-Position: refs/branch-heads/6778{#2} Cr-Branched-From: 7b1b7a0f51593df7a1a802f489d6a2fb14195bcc-refs/heads/main{#43221} UltraBlame original commit: 2655eb8ebb87254288bce7b0c7eeec6b6d96f1b8
gecko-dev-updater
pushed a commit
that referenced
this pull request
Dec 1, 2024
…izer data structures + logic., a=testonly Automatic update from web-platform-tests [Sanitizer] Reland: Implement core Sanitizer data structures + logic. This implements the core Sanitizer logic. This is still missing spec-mandated handling of "javascript:" URLs, and will have to be updated as the spec develops. But other than that, the basics are now there. ------------------ This a re-land of crrev.com/c/5922125. Patch set #1 is the original version, as reviewed and submitted there. Patch set #2 contains the fix. Analysis of the bug is in https://issues.chromium.org/issues/356601280#comment16 Bug: 356601280, 379235386, 379246316 Change-Id: I06d4a9a378330cc76015e3922b9e288d9503881a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6021482 Reviewed-by: Yifan Luo <lyfchromium.org> Reviewed-by: Joey Arhar <jarharchromium.org> Commit-Queue: Daniel Vogelheim <vogelheimchromium.org> Cr-Commit-Position: refs/heads/main{#1385522} -- wpt-commits: 348423995eb22e35d7fbb229a729839675e4ef01 wpt-pr: 49229 UltraBlame original commit: 949d805f0b0f8579ae3bcf59b6872a14ad9a8fa1
gecko-dev-updater
pushed a commit
that referenced
this pull request
Dec 1, 2024
…re matching., a=testonly Automatic update from web-platform-tests [SRI Message Signatures] Enforce signature matching. This patch teaches the network service's `URLLoader` how to evaluate the SRI-valid subset of HTTP Message Signatures, blocking mismatched responses once headers are received and processed. This check is implemented behind a new feature flag, which is disabled by default. End-to-end tests live in web platform tests under //web_tests/virtual/sri-message-signatures that enables the flag. This is part of a chain of CLs implementing this feature (#2 from https://wicg.github.io/signature-based-sri/#overview): 1. [Parsing] https://crrev.com/c/6020612 2. [Validation 1] https://crrev.com/c/6030571 3. [Validation 2] https://crrev.com/c/6032589 4. [Enforcement] https://crrev.com/c/6038714 [You are here] `url_loader.cc` are the only meaningful changes in behavior reported as undercovered. These are tested through the WPT included in this CL. Bug: 379534943 Low-Coverage-Reason: COVERAGE_UNDERREPORTED The changes to Change-Id: I6ece80da25ed4329a6f976c2c74c639c2799b856 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6038714 Reviewed-by: Kenichi Ishibashi <bashichromium.org> Reviewed-by: Camille Lamy <clamychromium.org> Reviewed-by: Kent Tamura <tkentchromium.org> Commit-Queue: Mike West <mkwstchromium.org> Cr-Commit-Position: refs/heads/main{#1389294} -- wpt-commits: 5d7e670ddb40d59c89d0a2a1b15afa813ff9169a wpt-pr: 49416 UltraBlame original commit: 4e4ebf3dd8765a13c16da03f3a2353dbe218fc4c
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bumps express from 2.5.11 to 4.17.1.
Release notes
Sourced from express's releases.
Changelog
Sourced from express's changelog.
Commits
e1b45eb4.17.10a48e18Revert "Improve error message for null/undefined to res.status"eed05a1build: [email protected]10c77564.17.09dadca2docs: remove Gratipay linksb8e5056tests: ignore unreachable line94e48a1build: update example dependenciesefcb17ddeps: [email protected]b9ecb9abuild: support Node.js 12.x5266f3abuild: test against Node.js 13.x nightlyMaintainer changes
This version was pushed to npm by dougwilson, a new releaser for express since your current version.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot ignore this [patch|minor|major] versionwill close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)@dependabot use these labelswill set the current labels as the default for future PRs for this repo and language@dependabot use these reviewerswill set the current reviewers as the default for future PRs for this repo and language@dependabot use these assigneeswill set the current assignees as the default for future PRs for this repo and language@dependabot use this milestonewill set the current milestone as the default for future PRs for this repo and languageYou can disable automated security fix PRs for this repo from the Security Alerts page.