Closed Bug 1622490 Opened 5 months ago Closed 4 months ago

Page doesn't finish loading

Categories

(Core :: Networking, defect, P2)

74 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla77
Tracking Status
firefox-esr68 --- unaffected
firefox75 --- wontfix
firefox76 --- verified
firefox77 --- verified

People

(Reporter: jadevree, Assigned: mattwoodrow)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [necko-triaged])

Attachments

(5 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

  1. Open firefox (with a clean profile)
  2. Open devtools (F12)
  3. navigate to https://bugzilla.kernel.org/ (the version of bugzilla here on mozilla.org doesn't seem to trigger the bug for me)
  4. Search for anything, I used "megaraid"

You can also cause it with the Browser Console (Ctrl+Shift+J) instead of devtools.

Actual results:

The screen just sits there blank acting like its loading.

Expected results:

The page should load.

There is a bonus glitch, if you select the HTTP request in the network tab and then select the Response tab, it completely breaks the network tab of devtools. See this additional screenshot.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Console
Product: Firefox → DevTools

This appears to be related to bugzilla's use of the multipart/x-mixed-replace content-type. The installation here on mozilla.org doesn't ever use that type, but the version on bugzilla.kernel.org (and others) will use it if your User-Agent is Firefox. If you change your UA to Chrome, bugzilla doesn't use that content-type and the page renders fine.

After looking at the bugzilla source, I've discovered that you can add "&serverpush=0" to the URL to disable this without User-Agent spoofing. If you do that the page will load just fine.

FF 73 and FF ESR 68.6 work fine, only FF 74 has trouble.

I can reproduce on 74, 75, but not on Nightly 76.

NUXI, could you check if this persists on Nightly as well for you?

Flags: needinfo?(jadevree)
Component: Console → Netmonitor

(In reply to :Harald Kirschner :digitarald from comment #4)

I can reproduce on 74, 75, but not on Nightly 76.

NUXI, could you check if this persists on Nightly as well for you?

The page renders for me under 76, but the loading animation continues forever. So its only partially fixed.

Flags: needinfo?(jadevree)

screenshot showing the page loading forever under nightly.

(Note: this screenshot taken from linux, the first two were from windows)

Thanks for reporting the issue!

I can reproduce the "loading-forever" issue.

This indeed seems to be related to bug 1611081

If I disable collecting HTTP Responses in the Network panel it works.

diff --git a/devtools/server/actors/network-monitor/network-observer.js b/devtools/server/actors/network-monitor/network-observer.js
--- a/devtools/server/actors/network-monitor/network-observer.js
+++ b/devtools/server/actors/network-monitor/network-observer.js
@@ -763,17 +763,17 @@ NetworkObserver.prototype = {
       }
     } else {
       event.blockedReason = blockedReason;
     }
 
     httpActivity.owner = this.owner.onNetworkEvent(event);
 
     if (!event.blockedReason) {
-      this._setupResponseListener(httpActivity, fromCache);
+      //this._setupResponseListener(httpActivity, fromCache);
     }
 
     httpActivity.owner.addRequestHeaders(headers, extraStringData);
     httpActivity.owner.addRequestCookies(cookies);
 
     return httpActivity;
   },

See the implementation of _setupResponseListener here
https://searchfox.org/mozilla-central/rev/4ccefc3181f9d237ef4ca8bd17b4e7c101ddf7b5/devtools/server/actors/network-monitor/network-observer.js#905-940

Honza

Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
Priority: -- → P2
Summary: devtools causes page loading to hang → Page doesn't finish loading

Nhi, this seems to be a follow up for bug 1611081. There are STRs and it's nicely reproducible.
Could we please triage, thanks!

Honza

Flags: needinfo?(nhnguyen)

Quite a few reports made recently. I am moving this to the Networking component to increase attention (looks like P1 to me).

Honza

Component: Netmonitor → Networking
Product: DevTools → Core

Matt, could you have a look at this issue please? Looks like a regression from bug 1611081.

Flags: needinfo?(nhnguyen) → needinfo?(matt.woodrow)
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)

The bug here is that bug 1611081 added support for forwarding OnAfterLastPart through nsStreamListenerTee, but not nsStreamListenerWrapper, which is also included in the listener chain when devtools starts watching loads.

Bug 1611081 made it so that OnAfterLastPart was observable by devtools, but it would never make it to HttpChannelParent/Child.

HttpChannelChild removes itself from the load group (and marks the load as complete), when it receives OnAfterLastPart (never, when devtools are open), or when it receives OnStopRequest with isLastPart=true.

Since isLastPart is unreliable, it's not always set to true on the last part (and is why we need OnAfterLastPart).

The testcase in bug 1611081 worked, because isLastPart was true on the last part and we ended the load without needing OnAfterLastPart. This testcase it's false, and without OnAfterLastPart, the load is never marked as complete.

I think we should stop using isLastPart in HttpChannelChild so that the behaviour is consistent, and so that we don't get bugs hidden for the cases where it's correct. I also think we should remove it entirely, but that's a separate bug.

Whiteboard: [necko-triaged]
Pushed by mwoodrow@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/01c6c54de477
Don't finish loading a multipart response in HttpChannelChild during OnStopRequest, since we should rely on OnAfterLastPart being called for this. r=mayhemer
https://hg.mozilla.org/integration/autoland/rev/400c3278b009
Add nsIMultiPartChannelListener forwarding to nsStreamListenerWrapper. r=mayhemer
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

The patch landed in nightly and beta is affected.
:mattwoodrow, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(matt.woodrow)

Comment on attachment 9140070 [details]
Bug 1622490 - Don't finish loading a multipart response in HttpChannelChild during OnStopRequest, since we should rely on OnAfterLastPart being called for this. r?mayhemer

Beta/Release Uplift Approval Request

  • User impact if declined: Multipart response pages (rare), may fail to finish loading (throbber shows active, but page content is complete) when devtools are open.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • 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): Very simple fix to pass a message on through an intermediate class
  • String changes made/needed:
Flags: needinfo?(matt.woodrow)
Attachment #9140070 - Flags: approval-mozilla-beta?
Attachment #9140071 - Flags: approval-mozilla-beta?

Comment on attachment 9140070 [details]
Bug 1622490 - Don't finish loading a multipart response in HttpChannelChild during OnStopRequest, since we should rely on OnAfterLastPart being called for this. r?mayhemer

Approved for 76.0b7.

Attachment #9140070 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9140071 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+

Reproduced the issue on Windows 10, Ubuntu 18.04 and MacOS 10.14 using Firefox Release version 74.0 Build ID 20200309095159
Verified fixed on Firefox Nightly Version 77.0a1 Build ID 20200422093542 and Beta Version 76.0b7 Build ID 20200421231527 on Windows 10, Ubuntu 18.04 and MacOS 10.14

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.