1555287 - Does not render everything

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P2)

Description

[stemind]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.157 Safari/537.36

Steps to reproduce:

1. Surf to https://www.blumenmaarsen.ch/c/c2/?c=startshowffbug
2. LOGIN with USERNAME ffbug PASSWORD aaa
3. You now see some form fields and 2 red links
4. Change the monh selector form Jan to Feb
5. Now mostly everything is not visible (compared to point 3).
   That effect is new since a recent FF update.
   In all other major browsers everything is OK.

Actual results:

5. Now mostly everything is not visible (compared to point 3).
   That effect is new since a recent FF update.
   In all other major browsers everything is OK.

Expected results:

5. Now mostly everything is not visible (compared to point 3).
   That effect is new since a recent FF update.
   In all other major browsers everything is OK.

Comment 1

[Alice0775 White]

I can reproduce the issue on Nightly69.0a1 Windows10.

And Other STR:

1. Surf to https://www.blumenmaarsen.ch/c/c2/?c=startshowffbug
2. LOGIN with USERNAME ffbug PASSWORD aaa
3. Reload (F5)

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9be01bc279250018ca2d84eb3b0621ffe4489b12&tochange=9243ddacadcca22365599b018d279a026cc51b8c

Regressed by:
9243ddacadcca22365599b018d279a026cc51b8c Andreas Farre — Bug 1515646 - Add FindWithName and FindChildWithName to BrowsingContext. r=peterv

Andreas Farre,
Your patch causes the regression. Can you please look into this?

Comment 3

[Alice0775 White]

[Tracking Requested - why for this release]: Missing page element, Browser compatible issue

Comment 4

[Julien Cristau [:jcristau]]

Neha can you get this triaged and looked at?

Comment 5

[Neha Kochar [:neha]]

(In reply to Julien Cristau [:jcristau] from comment #4)

Neha can you get this triaged and looked at?

Andreas is looking into this.

Comment 6

[Andreas Farre [:farre]]

Try is here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d2330d32ffd32baebcb1cce3872ed29eaf0ad54f&group_state=expanded

Comment 8

[Andreas Farre [:farre]]

Attachment: Bug 1555287 - Make sure to detach browsing context children early.

Waiting for docshells and frameloaders to destroy will leave attached
browsing contexts attached too long. In case the children of a
browsing contexts cannot be cached we want to detach all of them as
soon as possible.

Comment 9

[Andreas Farre [:farre]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=cf2a00c05fd52c5253eeb12b2f2521840918ba34&group_state=expanded

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c807d0b9d872
Make sure to detach browsing context children early. r=nika

Comment 11

[Noemi Erli[:noemi_erli]]

Backed out changeset c807d0b9d872 (Bug 1555287) for valgrind bustages CLOSED TREE

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=c807d0b9d8727c30c39ed43c4faf7f61d9eecb14&selectedJob=251592386

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=251601651&repo=autoland&lineNumber=39646

Backout: https://hg.mozilla.org/integration/autoland/rev/89f4dbd09188e319572bc7865852bde6b58db32a

Comment 12

[Cosmin Sabou [:CosminS]]

There are also these assertions that started from there: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=251608492&repo=autoland&lineNumber=1159

10:23:57 INFO - GECKO(8532) | Assertion failure: !mIsDiscarded, at z:/build/build/src/docshell/base/BrowsingContext.cpp:253
10:23:57 INFO - GECKO(8532) | #01: mozilla_dump_image[Z:\task_1560417845\build\application\firefox\xul.dll +0xdec77e1]
10:23:57 INFO - GECKO(8532) | #02: mozilla_dump_image[Z:\task_1560417845\build\application\firefox\xul.dll +0xdec1874]
10:23:57 INFO - GECKO(8532) | #03: mozilla_dump_image[Z:\task_1560417845\build\application\firefox\xul.dll +0xdec3cdd]
10:23:57 INFO - GECKO(8532) | #04: workerlz4_maxCompressedSize[Z:\task_1560417845\build\application\firefox\xul.dll +0xe835bf9]
10:23:57 INFO - GECKO(8532) | #05: workerlz4_maxCompressedSize[Z:\task_1560417845\build\application\firefox\xul.dll +0xea9737e]
10:23:57 INFO - GECKO(8532) | #06: workerlz4_maxCompressedSize[Z:\task_1560417845\build\application\firefox\xul.dll +0xea93eaa]
10:23:57 INFO - GECKO(8532) | #07: XRE_GetBootstrap[Z:\task_1560417845\build\application\firefox\xul.dll +0x11891cc2]
10:23:57 INFO - GECKO(8532) | #08: Ordinal0[Z:\task_1560417845\build\application\firefox\xul.dll +0x21c29a8]
10:23:57 INFO - GECKO(8532) | #09: Ordinal0[Z:\task_1560417845\build\application\firefox\xul.dll +0x21ca18f]
10:23:57 INFO - GECKO(8532) | #10: XRE_GetBootstrap[Z:\task_1560417845\build\application\firefox\xul.dll +0xee50a44]
10:23:57 INFO - GECKO(8532) | #11: XRE_GetBootstrap[Z:\task_1560417845\build\application\firefox\xul.dll +0xee53a45]
10:23:57 INFO - GECKO(8532) | #12: XRE_GetBootstrap[Z:\task_1560417845\build\application\firefox\xul.dll +0xee335d5]
10:23:57 INFO - GECKO(8532) | #13: XRE_GetBootstrap[Z:\task_1560417845\build\application\firefox\xul.dll +0xee167ab]
10:23:57 INFO - GECKO(8532) | #14: XRE_GetBootstrap[Z:\task_1560417845\build\application\firefox\xul.dll +0xee51332]
10:23:57 INFO - GECKO(8532) | #15: XRE_GetBootstrap[Z:\task_1560417845\build\application\firefox\xul.dll +0xee53a45]
10:23:57 INFO - GECKO(8532) | #16: XRE_GetBootstrap[Z:\task_1560417845\build\application\firefox\xul.dll +0xee53c97]
10:23:57 INFO - GECKO(8532) | #17: XRE_GetBootstrap[Z:\task_1560417845\build\application\firefox\xul.dll +0xfae5c42]
10:23:57 INFO - GECKO(8532) | #18: Ordinal0[Z:\task_1560417845\build\application\firefox\xul.dll +0x21af04c]
10:23:57 INFO - GECKO(8532) | #19: Ordinal0[Z:\task_1560417845\build\application\firefox\xul.dll +0x3606cb]
10:23:57 INFO - GECKO(8532) | #20: XRE_GetBootstrap[Z:\task_1560417845\build\application\firefox\xul.dll +0x11891d19]
10:23:57 INFO - GECKO(8532) | #21: Ordinal0[Z:\task_1560417845\build\application\firefox\xul.dll +0x2d16b6]
10:23:57 INFO - GECKO(8532) | #22: XRE_GetBootstrap[Z:\task_1560417845\build\application\firefox\xul.dll +0xeba8303]
10:23:57 INFO - GECKO(8532) | #23: workerlz4_maxCompressedSize[Z:\task_1560417845\build\application\firefox\xul.dll +0xeb63a13]
10:23:57 INFO - GECKO(8532) | #24: workerlz4_maxCompressedSize[Z:\task_1560417845\build\application\firefox\xul.dll +0xeb68379]
10:23:57 INFO - GECKO(8532) | #25: workerlz4_maxCompressedSize[Z:\task_1560417845\build\application\firefox\xul.dll +0xeb6a4af]
10:23:57 INFO - GECKO(8532) | #26: Ordinal0[Z:\task_1560417845\build\application\firefox\firefox.exe +0x1e85]
10:23:57 INFO - GECKO(8532) | #27: Ordinal0[Z:\task_1560417845\build\application\firefox\firefox.exe +0x14f3]
10:23:57 INFO - GECKO(8532) | #28: TargetNtUnmapViewOfSection[Z:\task_1560417845\build\application\firefox\firefox.exe +0xf6438]
10:23:57 INFO - GECKO(8532) | #29: BaseThreadInitThunk[C:\Windows\System32\KERNEL32.DLL +0x13034]
10:23:57 INFO - GECKO(8532) | #30: RtlUserThreadStart[C:\Windows\SYSTEM32\ntdll.dll +0x71461]
10:26:54 INFO - runtests.py | Waiting for browser...
10:26:54 INFO - TEST-INFO | Main app process: exit 80000003

Comment 13

[Andreas Farre [:farre]]

I have a fix, and if https://treeherder.mozilla.org/#/jobs?repo=try&revision=2bcdcfc0ceccbb35e389e25c6edfddca4115cad6&selectedJob=251650635 goes green I'll try and re-land.

Comment 14

[Andreas Farre [:farre]]

Try looks better now: https://treeherder.mozilla.org/#/jobs?repo=try&revision=2bcdcfc0ceccbb35e389e25c6edfddca4115cad6&selectedJob=251699976

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a30ecde306ef
Make sure to detach browsing context children early. r=nika

Comment 16

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/a30ecde306ef

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta approval when you get a chance.

EDIT: OK, maybe after looking at the possible crash regression from this first :-)

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

Possible crash, bug 1559537... do you think it is connected?

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

We may need to back this out for the crash in the related bug.

Comment 20

[Andreas Farre [:farre]]

As I said over in bug 1559537, backing out might be the best option.

Comment 21

[Andreas Farre [:farre]]

Attachment: Bug 1555287 - Make sure to detach browsing context children early. r=nika

Always move browsing contexts to the cache, even if we're not caching
the docshell. If we're not moving to bfcache, BrowsingContext::Detach
will detach as normal.

Comment 22

[Andreas Farre [:farre]]

Comment 21 expects that Comment 15 has been backed out.

Comment 23

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/897742f4ae26
Backed out changeset a30ecde306ef for causing bug 1559537 a=backout

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/695c34774fbc
Make sure to detach browsing context children early. r=nika

Comment 25

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/695c34774fbc

Comment 26

[Andreas Farre [:farre]]

Nika, this is the bug that needs a beta uplift request. I realized that we need to look at potential regressions before doing that, so I guess I won't be able to before PTO.

Comment 27

[Julien Cristau [:jcristau]]

We've already built 68 rc1. Since this bug was already present in 67 I don't think it's worth the risk of taking in a rc2. We can maybe uplift to a dot release in a little while if nothing pops up in beta 69, and/or to a later esr68 release.

Comment 28

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Hello all,
Managed to reproduce this issue with Nightly69.0a1 (2019-05-29) on Windows 10x64.

Confirming this issue as verified fixed on Nightly 70.0a1 (2019-07-11) and Nightly 69.0a1(2019-07-04) on Windows 10x64 , macOS 10.14 and Ubuntu 18.04x64.

Comment 29

[Adrian Walker]

I see that there is progress on 1555287. However 1554715* is still not fixed in v68. Hopefully it is being worked on? Thanks, --Adrian

• https://www.executable-english.com/ibl_login.html
  Click the GO button in the middle of the page
  click the Go button top right.

The top frame is not rendered in v67 or v68, but it worked fine in versions up to 66.

Comment 30

[Ryan VanderMeulen [:RyanVM]]

(In reply to Adrian Walker from comment #29)

I see that there is progress on 1555287. However 1554715* is still not fixed in v68. Hopefully it is being worked on? Thanks, --Adrian

This is currently fixed in v69+ (available to test on the Beta channel if you're interested). As noted in comment 27, it's possible this may eventually get fixed in a v68 point release, but that's not guaranteed either.

Comment 31

[Neha Kochar [:neha]]

Clearing Nika's ni as there is no uplift required at this time. We may come back to uplifting this for 68 when RelMan recommends so.

Comment 32

[Julien Cristau [:jcristau]]

(In reply to Neha Kochar [:neha] from comment #31)

Clearing Nika's ni as there is no uplift required at this time. We may come back to uplifting this for 68 when RelMan recommends so.

Seems there's some misunderstanding here. I'm relying on you to tell me whether you think this is ready for uplift, and what the risks are. Including status of the reported regressions.

Comment 33

[Andreas Farre [:farre]]

So this is already in beta, but the question is if this is something we want to have fixed in 68 (which is an esr) as well. I think that it should probably be safe enough for that, but I don't know the exact process for that. Is it the same as for beta?

Comment 34

[Ryan VanderMeulen [:RyanVM]]

Yes, you can request approval on the patch for Release (if you think it should go into a 68 dot release) and ESR68 (for a future 68.xesr release) with your reasoning for doing so.

Comment 35

[Andreas Farre [:farre]]

Comment on attachment 9073344 [details]
Bug 1555287 - Make sure to detach browsing context children early. r=nika

Beta/Release Uplift Approval Request

• User impact if declined: Site compatibility issues.
• Is this code covered by automated tests?: Unknown
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Has been verified on nightly.
• String changes made/needed: None

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Site compatibility issues.
• User impact if declined: Site compatibility issues.
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Has been verified on nightly.
• String or UUID changes made by this patch: None

Comment 36

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9073344 [details]
Bug 1555287 - Make sure to detach browsing context children early. r=nika

I don't think we want to take this in a 68 dot release at this point, but let's get this fixed in 68.1esr anyway.

Comment 37

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-esr68/rev/cd330a25b834

Comment 38

[Adrian Walker]

I see that Bug 1555287 "Does not render everything" is VERIFIED FIXED in Firefox -esr68

However I tried the test below using 68.0.1, and it fails to "render everything"

TEST:
https://www.executable-english.com/ibl_login.html
Click the GO button in the middle of the page
click the Go button top right.

RESULT: ERROR The top frame is not rendered, (but it worked fine in versions up to 66.)

Any estimate of how long it will take to fix? Thanks, - Adrian

Comment 39

[Ryan VanderMeulen [:RyanVM]]

The fix is due to ship in the 68.1esr release in early September. If the version is 68.0.x, it's not expected to be fixed.