Bug 911098 - Implement addon dubugger UI by Gozala · Pull Request #3 · mozilla/gecko-dev

Gozala · 2014-01-14T19:24:39Z

Note: This is just for a review, not for actually merging in.

Gozala · 2014-01-23T23:01:39Z

toolkit/mozapps/extensions/XPIProvider.jsm

@Mossop I believe @erikvold is going to expose isJetpack for native jetpacks anyway, so is there point in delaying it ?

I'd like Blair to review any API addition here.

On Thu, Jan 23, 2014 at 3:01 PM, Irakli Gozalishvili <
notifications@github.com> wrote:

In toolkit/mozapps/extensions/XPIProvider.jsm:

@@ -6594,6 +6594,22 @@ function AddonWrapper(aAddon) {
return ops;
});

this.defineGetter("isBootstrapped", function AddonWrapper_isBootstrapped() {

return this.operationsRequiringRestart === AddonManager.OP_NEEDS_RESTART_NONE;

});

this.defineGetter("isJetpack", function AddonWrapper_isJetpack() {

// Assume that if there's a harness-options.json file in restartless add-on

// it's a jetpack.

return this.isBootstrapped && this.hasResource("harness-options.json");

});

@Mossop https://github.com/Mossop I believe @erikvoldhttps://github.com/erikvoldis going to expose
isJetpack for native jetpacks anyway, so is there point in delaying it ?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/3/files#r9134079
.

erikvold · 2014-02-05T19:17:43Z

I believe @erikvold is going to expose isJetpack for native jetpacks anyway, so is there point in delaying it ?

@Mossop @Gozala that is part of the plan

@yurenju

======== https://hg.mozilla.org/integration/gaia-central/rev/3c7ae072e684 Author: Kyle Machulis <kyle@nonpolynomial.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 <kyle@nonpolynomial.com> Desc: Bug 969950 - Cleaning up distribution sample ======== https://hg.mozilla.org/integration/gaia-central/rev/de97a5d865ef Author: Kyle Machulis <kyle@nonpolynomial.com> Desc: Bug 969650 - Subtree merge of yurenju/gaia-distribution-sample ======== https://hg.mozilla.org/integration/gaia-central/rev/eb9ae9a4503f Author: Yuren Ju <yurenju@gmail.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 <jsmith@mozilla.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 <yurenju@gmail.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 <kevingrandon@yahoo.com> Desc: Add calendar.json ======== https://hg.mozilla.org/integration/gaia-central/rev/90aef8c4de58 Author: gasolin <gasolin@gmail.com> Desc: Create README.md ======== https://hg.mozilla.org/integration/gaia-central/rev/8f96ae99b519 Author: Yuren Ju <yurenju@gmail.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 <gasolin@gmail.com> Desc: add runtime customize for bookmark setting ======== https://hg.mozilla.org/integration/gaia-central/rev/4e64191b5493 Author: Yuren Ju <yurenju@gmail.com> Desc: Initial commit

…ps,rnewman

…e on windows platform,mozilla#3 code format

edmorley · 2014-08-19T19:03:02Z

(Mass-PR-close)
This PR is against gecko-dev, which is read only. Did you mean to submit it against another repo?
Changes to repos covered by gecko-dev must be made to the hg.mozilla.org repo, which is then mirrored here. Please see:
https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F

Whitespace cleanup

Added ci-build mach command

… 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]

Limit the area of the surface rather than width and height

…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 --HG-- extra : commitid : LPnSogXNNio extra : rebase_source : 0564dd5688916271c4a709ae6f15ba7ad493a761

CloudStorageServiceAPI and CloudStorageManager integration

Bug 1270701-Draw a cursor when a mouse is being used; a=jocheng

Masayuki suggests GetCharcterRectsInRange instead of first idea's API by part 2 implementation. IME wants to need the width per character. Now nsTextFrame/nsIFrmae has only API to get point of string. So I want to add this method to calculate simply by comment #3. If no text frame, I would like to return error due to no character. (Caller shouldn't call this API on non-text frame.) MozReview-Commit-ID: LQHUTzhnGn --HG-- extra : rebase_source : bc495493c7be73afb05489ad2169e8dcdd6e6da4 extra : histedit_source : e54a7c3bfb100765317a0c8a83b432d5f706ffe1

…dle the case when queried range starts from the end of mRootContent r=smaug First, when the first node causing text is invisible, OnQueryTextRect() still fails even with this patch. We shouldn't fix it in this bug because it's unusual case but this bug is very important especially for some web service using HTML editor like Gmail. This patch fixes all cases when the start offset of queried range reaches the end of mRootContent. 1. When the last node causing text is a element (either content element or moz- element), its frame is a placeholder for empty line. Therefore, this patch sets the rect to the frame rect. 2. When the last node causing text is a text node, the last frame generated for it represents its line (including empty line). Therefore, this patch sets the rect to the result of GetLineBreakerRectAfter(). 3. When the last node causes a line breaker before it, the frame may be a placeholder for it (this is not usual case, when user types Enter key at the end of element, is generated by Gecko). In this case, this patch sets a possible caret rect which is guessed from the content box of the frame and its font height. 4. When there are no nodes causing text in mRootContent, this patch sets a possible caret rect like case #3. MozReview-Commit-ID: FS9cWJQ39DK --HG-- extra : rebase_source : cb2ea4cfb4c8d5c85a4dd7498aa11bd86b61c2ef

…dle the case when queried range starts from the end of mRootContent r=smaug First, when the first node causing text is invisible, OnQueryTextRect() still fails even with this patch. We shouldn't fix it in this bug because it's unusual case but this bug is very important especially for some web service using HTML editor like Gmail. This patch fixes all cases when the start offset of queried range reaches the end of mRootContent. 1. When the last node causing text is a element (either content element or moz- element), its frame is a placeholder for empty line. Therefore, this patch sets the rect to the frame rect. 2. When the last node causing text is a text node, the last frame generated for it represents its line (including empty line). Therefore, this patch sets the rect to the result of GetLineBreakerRectAfter(). 3. When the last node causes a line breaker before it, the frame may be a placeholder for it (this is not usual case, when user types Enter key at the end of element, is generated by Gecko). In this case, this patch sets a possible caret rect which is guessed from the content box of the frame and its font height. 4. When there are no nodes causing text in mRootContent, this patch sets a possible caret rect like case mozilla#3. MozReview-Commit-ID: FS9cWJQ39DK

Add in endpoints for modal dialog support Source-Repo: https://github.com/mozilla/geckodriver Source-Revision: 83b4de3af8ac59ae394d74f64280b3b69d8a3594 --HG-- extra : rebase_source : a3237e8c0d5d5c82360a2835da31a7ac59fa0592

Add in endpoints for modal dialog support Source-Repo: https://github.com/mozilla/geckodriver Source-Revision: 83b4de3af8ac59ae394d74f64280b3b69d8a3594

… r=Pike MozReview-Commit-ID: IHhE3xg3nb0 --HG-- extra : rebase_source : 3135b6d5c716e1359ad7fc5ae21d6885e9918543

…ng in 0 r=Pike MozReview-Commit-ID: IHhE3xg3nb0

…the last page was processed. r=jwatt For the last page, here is the final three messages sent between the content process, RemotePrintJobChild, and the chrome process, RemotePrintJobParent, for printing: 1. The content process sends *ProcessPage* to the chrome process via SendProcessPrint to request the chrome process print the last page. 2. The content process sends *FinalizePrint* to the chrome process via SendFinalizePrint to notify the chrome that there are no more outstanding print requests, and that the chrome process can release interal resource now. 3. The content process receive PageProcessed message from the chrome process. This calling sequence is fine for sync style PrintTarget (even though the FinalizePrint message is sent out a bit ealy). Since a sync PrintTarget completes its print task right after receiving *ProcessPage* message in #1, sending FinalizePrint before getting PageProcessed response is harmless. But this message dispatching sequence does cause a problem for async style PrintTargetEMF. After getting a message sent in #2, PrintTargetEMF release all resources before getting a EMF conversion response from the PDFium process. So the last page can not be printed correctly. This patch reorder the #2 and #3 message, that is to send FinalizePrint after the content process received PageProcessed message of the last page. MozReview-Commit-ID: 9ZVSrFnuHBU --HG-- extra : rebase_source : d12161e1c8ac6469fc1ecb9514939bd35979d573 extra : source : 70ce23becf8840408cd72e7f933a167090519c09

…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

…or fixed, a=testonly Automatic update from web-platform-tests [LayoutNG] Fix for DCHECK(NeedsLayout) for fixed All tests pass, and crashes no longer happen. I believe that code will not longer crash, but there might be futher instances of incorrect positioning. Fix #1 LayoutDescendantCandidates did not sweep newly discovered candidates. This was done manually once inside NGOutOfFlowLayoutPart::Run, and sweep was not performed for LayoutDescendantCandidates found in Legacy. Fix is to make LayoutDescendantCandidates perform sweep instead. Fix #2 fix #1 exposed a bug where duplicate fragments were generated for a single layout object. This happened when NG was generating fragments not inside ContainingBlock. Fix one instance of this inside NGOutOfFlowLayoutPart::IsContainingBlockForDescendant by making sure that OOF with inline containers are only positioned inside its ContainingBlock() Fix #3 NGOutOfFlowLayoutPart::LayoutDescendant offset adjustment. Bug: 935805 Change-Id: I9f7ebbc7223f40fbbf6ba3739d9385bfd59e3641 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1517093 Commit-Queue: Aleks Totic <atotic@chromium.org> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#641628} -- wpt-commits: c748846db4d54c5b1c93659d9458698871a98eea wpt-pr: 15794

…e changes to 'none'", a=testonly Automatic update from web-platform-tests Revert "Correctly handle scroll-snap-type changes to 'none'" This reverts commit 712c3cf3ed8201420acf23f760eaa34be20781cd. Reason for revert: This patch causes webkit-layout-tests failure on WebKit_Linux_Trusty_ASAN bot: https://ci.chromium.org/p/chromium/builders/ci/WebKit%20Linux%20Trusty%20ASAN/25720 Unexpected Failures: * external/wpt/css/css-scroll-snap/scroll-snap-type.html * virtual/threaded/external/wpt/css/css-scroll-snap/scroll-snap-type.html STDERR: ==1==ERROR: AddressSanitizer: heap-use-after-free on address 0x61200023f8d8 at pc 0x5620c924e56d bp 0x7ffde3c56830 sp 0x7ffde3c56828 STDERR: READ of size 8 at 0x61200023f8d8 thread T0 (content_shell) STDERR: #0 0x5620c924e56c in get ./../../base/memory/scoped_refptr.h:212:27 STDERR: #1 0x5620c924e56c in Style ./../../third_party/blink/renderer/core/layout/layout_object.h:1615:0 STDERR: #2 0x5620c924e56c in GetPhysicalSnapType ./../../third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc:88:0 STDERR: #3 0x5620c924e56c in blink::SnapCoordinator::UpdateSnapContainerData(blink::LayoutBox&) ./../../third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc:107:0 STDERR: #4 0x5620c924e74b in blink::SnapCoordinator::UpdateAllSnapContainerData() ./../../third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc:76:5 Original change's description: > Correctly handle scroll-snap-type changes to 'none' > > > Previously when a scroll container's snap type is changed to 'none' its > data was discarded including all of its snap areas. However this is > incorrect. Because while the snap type is 'none', the element is still > a scroll container which per spec [1] means that is should continue to > captures the snap areas in its subtree for whom it is the nearest > ancestor scroll container . The only difference is that it no longer > snaps. > > The fix is that we no longer remove the snap container data just > because is has a 'none' snap type and instead keep it and its snap > areas. But we check the snap type before performing any snap. > > To ensure this does not introduce any performance regression, this CL > also includes an optimization where we avoid re-calculating > snap_container_data when the snap type is 'none'. So keeping these snap > data should not be cheap. > > Note that there is another problem where if the current snap container > is no longer a scroll container (e.g., overflow: scroll => overflow: > visible) we release its snap areas and they become "orphan". But if we > are to do this correctly, we should re-assign these areas to the next > stroller in the chain. Similarly when an element becomes a scroll > container, it can potentially take over snap areas from its parent snap > container. > > > This patch does not address that situation yet but fixes the easier > problem. > > [1] https://drafts.csswg.org/css-scroll-snap/#overview > > Bug: 953575 > Test: > - wpt/css/css-scroll-snap/scroll-snap-type-change.html => Changing snap-type should work correctly > - wpt/css/css-scroll-snap/scroll-snap-type.html => Add a specific test for type 'none' to ensure it does not snap > > Change-Id: Ie493ad68ecba818ed41c0ee103ccf44725ff6e3f > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1589899 > Reviewed-by: Majid Valipour <majidvp@chromium.org> > Reviewed-by: David Bokan <bokan@chromium.org> > Commit-Queue: Majid Valipour <majidvp@chromium.org> > Cr-Commit-Position: refs/heads/master@{#657460} TBR=bokan@chromium.org,majidvp@chromium.org Change-Id: I3a327f6e342e95d045194d24ceaf49de52b2b921 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 953575 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1600437 Reviewed-by: Takashi Sakamoto <tasak@google.com> Commit-Queue: Takashi Sakamoto <tasak@google.com> Cr-Commit-Position: refs/heads/master@{#657571} -- wpt-commits: 59ffeb608fd8491995002d5c1dce17d4e49c5291 wpt-pr: 16724

…directly as far as possible r=smaug Most commands are dispatched only when the `document` has `contenteditable` or in `designMode`. In such case, command context is considered with the following order: 1. `HTMLEditor` for the document. 2. `TextEditor` if the document has focus and it has `TextEditor`. 3. Other command controller table associated with window or DocShell. In the case of #1 and #2, `ExecCommand()` can use `EditorCommand` directly and we only need to send subject principal to the editor only in these cases. In the case of #3, we need to fall back to traditional path. There are 2 paths: 1. If it's "paste" command, handle it with `nsCommandManager` to dispatch "paste" event. 2. If it's "cur" or "copy", handle it with `DocShell` to dispatch "cut" or "copy" event in the window or focused sub-document. Note that clipboard "cut" and "copy" commands are special cases. Only them were handled by `DocShell` instead of `nsCommandManager` This difference caused making active element's `TextEditor` is preferred rather than `HTMLEditor`. Although this behavior is better than our traditional behavior because Chromium works as so. But for now, we should keep our behavior. Finally, this patch makes `ExecCommand()` creates `nsCommandParams` instance since now, `EditorCommand` class can take only necessary parameter without it. Differential Revision: https://phabricator.services.mozilla.com/D29632 --HG-- extra : moz-landing-system : lando

`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 --HG-- extra : moz-landing-system : lando

`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 mozilla#2 and mozilla#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

…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

…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 --HG-- extra : moz-landing-system : lando

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

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

…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

… on windows platform,mozilla#3 code format

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

…,r=gfx-reviewers,lsalzman Original patch by Erik Kurzinger: D118304 The following is currently not well-defined by the EGL specification: 1. Create context. 2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces) 3. Make it current with a default framebuffer (ie with some draw/read surfaces) After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK? With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL backend currently assumes this behavior. However with the proprietary NVIDIA driver the answer is actually GL_NONE, meaning any rendering done after step #3 will be lost. As a fix, Firefox can simple call glDrawBuffer after making a surface current to set the draw buffer appropriately, either to GL_BACK for a double-buffered surface or to GL_FRONT for single-buffered. As mentioned above, this is redundant on Mesa, but should also be harmless. Differential Revision: https://phabricator.services.mozilla.com/D118743

… GL,r=gfx-reviewers,lsalzman Original patch by Erik Kurzinger: D118304 The following is currently not well-defined by the EGL specification: 1. Create context. 2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces) 3. Make it current with a default framebuffer (ie with some draw/read surfaces) After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK? With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL backend currently assumes this behavior. However with the proprietary NVIDIA driver the answer is actually GL_NONE, meaning any rendering done after step #3 will be lost. As a fix, Firefox can simple call glDrawBuffer after making a surface current to set the draw buffer appropriately, either to GL_BACK for a double-buffered surface or to GL_FRONT for single-buffered. As mentioned above, this is redundant on Mesa, but should also be harmless. Differential Revision: https://phabricator.services.mozilla.com/D118743

…t-in add-on (server side). r=rpl - `test_redirect_{final,two_hops,three_hops}` correspond to SSR #1 - `test_no_event_when_search_engine_not_used` corresponds to SSR #2 - `test_redirect_chain_does_not_start_on_first_request` corresponds to SSR #3 - `test_two_extensions_reported` corresponds to SSR #4 Differential Revision: https://phabricator.services.mozilla.com/D129176

…all `WhiteSpaceVisibilityKeeper::PrepareToSplitBlockElement()` before splitting a text node r=m_kato,smaug It does the following things when caret is collapsed in a text node in a `` or `<div>` element. 1. Split the text node containing caret to insert ` ` element 2. Insert ` ` element after it 3. Split ancestor elements which inclusive descendants of the `` or `<div>` 4. Delete the ` ` element if unnecessary from the left paragraph #3 and #4 are performed by `HTMLEditor::SplitParagraph()` and it calls `WhiteSpaceVisibilityKeeper::PrepareToSplitBlockElement()` correctly before splitting the block. However, in the case (caret is at middle of a text node), the text has already been split to 2 nodes because of #1. Therefore, it fails to handle to keep the white-space visibility. So that I believe that the root cause of this bug is, the method does much complicated things which are required, and doing the redundant things will eat memory space due to undo transactions. However, for now, I'd like to fix this with a simple patch which just call the preparation method before splitting the text node because I'd like to uplift this if it'd be approved (Note that this is not a recent regression, the root cause was created by bug 92686 which was fixed in 17 years ago: <https://searchfox.org/mozilla-central/commit/2e66280faef73e9be218e00758d4eb738395ac83>, but must be annoying bug for users who see this frequently). The new WPTs are pass in Chrome. Differential Revision: https://phabricator.services.mozilla.com/D130950

…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

Removed all Non-SpiderMonkey Files

…on r=glandium Since mozglue is now aware of Gecko process-types, remove the configurator for this bug's associated experiment. Instead, use `GeckoProcessType` directly in mozjemalloc. This requires a couple of adjustments for non-Firefox uses of mozjemalloc: - Since `logalloc-replay` uses mozjemalloc in an odd way, tweak its `moz.build` to also include `mozglue/misc/ProcessType.cpp`. - Since `GeckoProcessType` is not available in standalone SpiderMonkey builds, make the mostly-arbitrarily choice to always stall there. No functional changes. Differential Revision: https://phabricator.services.mozilla.com/D155300

Upstream commit: https://webrtc.googlesource.com/src/+/784f4cbcc24dc1db6be86bd706858cc773e816f2 dcsctp: Abandon chunks marked for fast retransmit The current code assumed that chunks that were scheduled for fast retransmission would never be abandoned, as chunks marked for fast retransmission would be immediately sent after the SACK has been processed, giving no time for them to be abandoned. But fuzzers keep on fuzzing, and can craft a sequence of chunks that result in a SACK that both marks the chunks for fast retransmission and later (while processing the same SACK) abandons them. (cherry picked from commit 7726b7d067789f57b18072b928fcada337115d1c) Bug: chromium:1331087 Change-Id: Id218607e18a6f3a9d6d51044dccb920e1e77372a Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264960 Commit-Queue: Florent Castelli <orphis@webrtc.org> Auto-Submit: Victor Boivie <boivie@webrtc.org> Reviewed-by: Florent Castelli <orphis@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#37108} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265163 Cr-Commit-Position: refs/branch-heads/5060@{mozilla#3} Cr-Branched-From: 1389c76d9c79839a2ca069df1db48aa3f2e6a1ac-refs/heads/main@{#36868}

Gozala added 2 commits January 13, 2014 10:57

apply original patch from @MHordecki

711aba9

Address review comments.

2364157

Gozala reviewed Jan 23, 2014
View reviewed changes

irvingreid pushed a commit to Nephyrin/mozilla-git that referenced this pull request Apr 29, 2014

Bug 966674: mozilla#3 Add parameter substitution in log messages; r=g…

30b56f1

…ps,rnewman

vagouzhou added a commit to vagouzhou/gecko-dev that referenced this pull request Aug 10, 2014

#1refactoring device info logic , #2 fix some incorrect conflict merg…

35f13b9

…e on windows platform,mozilla#3 code format

edmorley closed this Aug 19, 2014

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

Merge pull request mozilla#3 from martinthomson/whitespace

23a54b0

Whitespace cleanup

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

Merge pull request mozilla#3 from gregarndt/mach_ci_build

8d8d61e

Added ci-build mach command

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

Merge pull request mozilla#3 from monich/max_image_size

7efd537

Limit the area of the surface rather than width and height

weilonge referenced this pull request in weilonge/gecko-dev Nov 10, 2015

Merge pull request #3 from MozCloudStorage/cloud

1fbc5f1

CloudStorageServiceAPI and CloudStorageManager integration

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

Merge pull request mozilla#3 from fatseng/b2g48_v2_6

cff6660

Bug 1270701-Draw a cursor when a mouse is being used; a=jocheng

moz-v2v-gh pushed a commit that referenced this pull request Nov 18, 2017

Bug 1415896 - Update plural rule #3 (lv, ltg) for numbers ending in 0…

6189920

… r=Pike MozReview-Commit-ID: IHhE3xg3nb0 --HG-- extra : rebase_source : 3135b6d5c716e1359ad7fc5ae21d6885e9918543

JerryShih pushed a commit to JerryShih/gecko-dev that referenced this pull request Nov 21, 2017

Bug 1415896 - Update plural rule mozilla#3 (lv, ltg) for numbers endi…

cd99fdb

…ng in 0 r=Pike MozReview-Commit-ID: IHhE3xg3nb0

daoshengmu pushed a commit to daoshengmu/gecko-dev that referenced this pull request Nov 21, 2017

Bug 1415896 - Update plural rule mozilla#3 (lv, ltg) for numbers endi…

6ea0365

…ng in 0 r=Pike MozReview-Commit-ID: IHhE3xg3nb0

lissyx pushed a commit to lissyx/gecko-dev that referenced this pull request May 20, 2020

Fix mozilla#3: Properly cast from void*

13083ee

lissyx pushed a commit to lissyx/gecko-dev that referenced this pull request May 20, 2020

Fix mozilla#3: Properly cast from void*

2b2d589

vagouzhou added a commit to vagouzhou/gecko-dev that referenced this pull request Dec 1, 2020

1refactoring device info logic , #2 fix some incorrect conflict merge…

12a7121

… on windows platform,mozilla#3 code format

mdashti referenced this pull request in mongodb-forks/spidermonkey Feb 3, 2022

Removed all Non-SpiderMonkey Files (#3)

d57472c

Removed all Non-SpiderMonkey Files

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

Replace logo and about page, fixes mozilla#3 and mozilla#4

609c1be

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bug 911098 - Implement addon dubugger UI#3

Bug 911098 - Implement addon dubugger UI#3
Gozala wants to merge 2 commits intomozilla:masterfrom
Gozala:bug/addon-dubugger-ui@911098

Gozala commented Jan 14, 2014

Uh oh!

Gozala Jan 23, 2014

Uh oh!

Mossop Jan 23, 2014

Uh oh!

erikvold commented Feb 5, 2014

Uh oh!

edmorley commented Aug 19, 2014

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

Gozala commented Jan 14, 2014

Uh oh!

Gozala Jan 23, 2014

Choose a reason for hiding this comment

Uh oh!

Mossop Jan 23, 2014

Choose a reason for hiding this comment

Uh oh!

erikvold commented Feb 5, 2014

Uh oh!

edmorley commented Aug 19, 2014

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants