Does not render everything

VERIFIED FIXED in Firefox -esr68

Status

()

defect
P2
normal
VERIFIED FIXED
3 months ago
20 days ago

People

(Reporter: stemind, Assigned: farre)

Tracking

(Depends on 1 bug, Regression, Regressed 1 bug, {regression, reproducible, site-compat})

67 Branch
mozilla69
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Fission Milestone:M4, firefox-esr60 unaffected, firefox-esr6869+ fixed, firefox67 wontfix, firefox67.0.1- wontfix, firefox68+ wontfix, firefox69+ verified, firefox70+ verified)

Details

Attachments

(1 attachment, 1 obsolete attachment)

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:

  1. 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:

  1. 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.

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)
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout
Ever confirmed: true
Product: Firefox → Core

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?

Flags: needinfo?(afarre)
Regressed by: 1515646
Component: Layout → Document Navigation

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

Neha can you get this triaged and looked at?

Flags: needinfo?(nkochar)
Assignee: nobody → afarre
Flags: needinfo?(afarre)
Status: NEW → ASSIGNED

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

Neha can you get this triaged and looked at?

Andreas is looking into this.

Flags: needinfo?(nkochar)
Priority: -- → P2
Duplicate of this bug: 1554715

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.

See Also: → 1558176
Attachment #9069585 - Attachment description: Bug 1555287 - Make sure to detach browsing context children early. r=peterv → Bug 1555287 - Make sure to detach browsing context children early.
Pushed by afarre@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c807d0b9d872
Make sure to detach browsing context children early. r=nika

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

Flags: needinfo?(afarre)
Fission Milestone: --- → M3
Pushed by afarre@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a30ecde306ef
Make sure to detach browsing context children early. r=nika
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

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

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

Flags: needinfo?(afarre)

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

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

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

Flags: needinfo?(afarre)

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 21 expects that Comment 15 has been backed out.

Backout by aciure@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/897742f4ae26
Backed out changeset a30ecde306ef for causing bug 1559537 a=backout
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla69 → ---
Regressions: 1559537
Regressions: 1560110
Regressions: 1560220
Attachment #9069585 - Attachment is obsolete: true
Pushed by afarre@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/695c34774fbc
Make sure to detach browsing context children early. r=nika
Status: REOPENED → RESOLVED
Closed: 2 months ago2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

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.

Flags: needinfo?(nika)

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.

Fission Milestone: M3 → M4
Flags: qe-verify+
QA Contact: vlad.lucaci

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

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

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

(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.

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.

Flags: needinfo?(nika)

(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.

No longer regressions: 1559202

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?

Flags: needinfo?(jcristau)

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.

Flags: needinfo?(jcristau)

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
Attachment #9073344 - Flags: approval-mozilla-release?
Attachment #9073344 - Flags: approval-mozilla-esr68?

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.

Attachment #9073344 - Flags: approval-mozilla-release?
Attachment #9073344 - Flags: approval-mozilla-release-
Attachment #9073344 - Flags: approval-mozilla-esr68?
Attachment #9073344 - Flags: approval-mozilla-esr68+

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

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.

Regressions: 1560474
You need to log in before you can comment on or make changes to this bug.