Inspector goes blank when start downloading a file

NEW
Unassigned

Status

defect
P3
normal
2 years ago
2 months ago

People

(Reporter: 684sigma, Unassigned)

Tracking

({regression})

53 Branch
Dependency tree / graph

Firefox Tracking Flags

(firefox52 unaffected, firefox53 fix-optional, firefox54 fix-optional)

Details

Attachments

(1 attachment)

Reporter

Description

2 years ago
I have a problem with Firefox Beta 53, Firefox Nightly 55. It doesn't happen in Firefox ESR 45.
Sometimes when I download files, all text in inspector disappears.
I noticed one specific scenario when it happens

1. Open https://bugzilla.mozilla.org/show_bug.cgi?id=1347370
2. Open Devtools -> Inspector, add "download" attribute to any link on the page
3. Click that link

Result: All text in inspector disappears
Expected: Text in inspector should be visible without reopening devtools
Reporter

Updated

2 years ago
Has STR: --- → yes
Keywords: regression

Updated

2 years ago
Status: UNCONFIRMED → NEW
Has Regression Range: --- → no
Ever confirmed: true
Summary: All text in Inspector disappears when downloading a file → Inspector goes blank when start downloading a file

Comment 1

2 years ago
Reg range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a105cf2d33a5643d63c516d5ecfe917d8eb5eeee&tochange=fb4f5c7e082a4176cd1b8f3c784e5f424417e3fa

Alexandre Poirot — Bug 1151909 - Make the inspector actor wait for DOMContentLoaded instead of load. r=pbro
Blocks: 1151909
Has Regression Range: no → yes
Flags: needinfo?(poirot.alex)
OS: Unspecified → All
Hardware: Unspecified → All
Inspector bug triage (filter on CLIMBING SHOES).
Priority: -- → P2

Updated

a year ago
Duplicate of this bug: 1448541

Updated

a year ago
Duplicate of this bug: 1393455

Updated

a year ago
Duplicate of this bug: 1456462

Updated

a year ago
Duplicate of this bug: 1464241

Updated

11 months ago
Product: Firefox → DevTools

Updated

4 months ago
Duplicate of this bug: 1519810

Comment 8

4 months ago

It seems this issue reported two years back and not resolved yet on both of my Firefox - Quantum 64.0.2 (64-bit) and Developer Edition 66.0b2 (64-bit) . It will be nice if we get a fix for this problem.

Assignee: nobody → mratcliffe
Status: NEW → ASSIGNED
Flags: needinfo?(poirot.alex)

STR

  1. Open this test.
  2. Open the Inspector.
  3. Click the link.

Actual

The markup view goes blank.

Expected

The markup view does not go blank.

@bz Sorry to bug you!

In DevTools we use a nsIWebProgress listener to detect new pageloads (onDOMContentLoaded etc. are all way too late):

webProgress.addProgressListener(this,
                                Ci.nsIWebProgress.NOTIFY_STATE_WINDOW |
                                Ci.nsIWebProgress.NOTIFY_STATE_DOCUMENT);

The onStateChange handler is here:
https://searchfox.org/mozilla-central/source/devtools/server/actors/targets/browsing-context.js#1628

The problem is that if we have a download link e.g. <a href="image.png" download=""> and somebody clicks on it then this is picked up by the web progress listener and we tear down the markup view ready to set it up for the new document.

How can we detect from within onStateChange() that this is a download so that we can ignore the event?

Flags: needinfo?(bzbarsky)

Sorry for the lag here... I'm not sure how this fell through the cracks.

So it sounds like right now the devtools code is listening STATE_START|STATE_IS_DOCUMENT or something? That gets fired when we first send a request to the server.

We don't know whether it's a download or not until we receive a response from the server. The server may respond with a MIME type we don't know how to handle, or with "Content-disposition: attachment", and those would be downloads. Or the server can respond with a cross-origin redirect and that will not be a download, even if the "download" attribute is present. Or the server can respond with an HTTP 204 and that will be neither a download nor a navigation.

Presumably what you really want to know is "we're about to navigate away from this document" and switch to a different document, which will happen after we get the server response.

Does the pagehide event do what you want? If not, why not?

Flags: needinfo?(bzbarsky) → needinfo?(mratcliffe)

We should be able to make use of the pagehide event for this.

Assignee: mratcliffe → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(mratcliffe)
Duplicate of this bug: 1537970
You need to log in before you can comment on or make changes to this bug.