Closed Bug 1420419 Opened 2 years ago Closed 2 years ago

Extension page unresponsive when visiting a blob URL

Categories

(WebExtensions :: General, defect, P1)

defect

Tracking

(firefox59 verified)

VERIFIED FIXED
mozilla59
Tracking Status
firefox59 --- verified

People

(Reporter: danny0838, Assigned: baku)

References

(Depends on 1 open bug)

Details

(Keywords: hang)

Attachments

(10 files)

Attached file open-blob-bug.zip
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171024165158

Steps to reproduce:

1. Download the attachment, unzip it, and install the test addon in Firefox.
2. Click the browseraction to open the test page.
3. Click the test 1~6 in the test page.

(The tests are:
1. location.href = "BLOB_URL"
2. click a[href="BLOB_URL"]
3. click a[download][href="BLOB_URL"]
4. click a[target="_blank"][href="BLOB_URL"]
5. window.open("BLOB_URL")
6. browser.tabs.create({url: "BLOB_URL"})
)


Actual results:

In some versions of Firefox[1], the test page becomes unresponsive[2] after clicking the test 1, 2, 3, and sometimes 6.

[1]: On my computer it happens on portable Firefox 51~55, and not on Firefox 56~58. But at least 2 users reported to me that it happens on Firefox 57 as well. (Tests are in a Firefox that's newly installed, clean profile, and no other addon)
[2]: When the page becomes "unresponsive", it turns into blank and looks like it's loading something, but the loading never completes.


Expected results:

The page should download the blob normally in all tests 1~6.
Component: Untriaged → WebExtensions: General
Keywords: hang
Product: Firefox → Toolkit
What happens here is:

1. when one of those links is clicked, the blobURL is unregistered because nsGlobalWindowInner calls nsIGlobalObject::UnlinkHostObjectURIs.
2. A new content process is spawned for the loading of that blobURL.
3. A list of active blobURLs is sent from parent to content process. But that blobURL is not active anymore and it's not sent.
4. The loading fails because the blobURL is unknown.

This doesn't happen on a 'normal' navigation because we use a timer to keep blob URLs alive for 1 seconds after revoking and usually the the new page runs on the same process.  We could implement a similar behavior, based on a timer, also for blobs URLs shared between processes.
Duplicate of this bug: 1331176
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Assignee: nobody → amarchesini
(In reply to Andrea Marchesini [:baku] from comment #1)
> What happens here is:
> ...

Thank you for the investigation and explanation. I'd like to know why this happen on some Firefox installation and not some others? Does it depend on Firefox version or another factor? This is important to me since I need a good definition for when this bug would happen to implement a workaround in my addon to provide a good downward compatibility for older Firefox versions.
Attached patch blobURL.patchSplinter Review
I'm not particularly happy about this patch. Here what it does:

1. DataInfo is used to store active blobs and URLs. I added a revoked boolean in order to know which one of them are not active. Those are not returned by GetDataInfo() in order to keep the current behavior.

2. We have ReleasingTimerHolder currently set to 1 second that is used to revoke blobURL for real. I expanded that in order to send notification to other processes when the timer expires. This means that the content A will receive a revoke notification after a while. This is what doesn't make me particularly happy.

3. revoke state is shared via IPC so that ContentChild can start the timer immediately when the list of blob URLs is received.
Attachment #8931841 - Flags: feedback?(bugs)
Isn't the addon basically broken? It expects rather odd blob url handling.

The timeout is really error prone, as is the current timeout we already have.
Timeout makes also the API work rather magically cross processes.

Danny, could the addon create the blob url in a context which stays alive long enough and then the url would be explicitly revoked when needed?
Comment on attachment 8931841 [details] [diff] [review]
blobURL.patch

Oh, hmm, do we need this also for cases like when we might open link in a new process.
Could you test a bit, with noopener or perhaps with ctrl+click on a <a> with blob url or so.

Not too happy though, but I don't have good ideas how else to fix this.
Attachment #8931841 - Flags: feedback?(bugs) → feedback+
(In reply to Olli Pettay [:smaug] from comment #5)
> Isn't the addon basically broken? It expects rather odd blob url handling.
> 
> The timeout is really error prone, as is the current timeout we already have.
> Timeout makes also the API work rather magically cross processes.
> 
> Danny, could the addon create the blob url in a context which stays alive
> long enough and then the url would be explicitly revoked when needed?

It is a very commonly used technique to create a a[download][href="BLOB_URL"] to download a dynamically generated BLOB for normal web sites. How can it be "broken" and "odd" for addons?

a[download] defines that it's an attachment rather than a normal link. The Firefox behavior that the page "visits" the clicked a[download] (and gets blobs revoked) rather than just prompt a download should be an error anyway.
> Could you test a bit, with noopener or perhaps with ctrl+click on a <a> with
> blob url or so.

In this case it works because the 'parent' window is still keeping the blobURL alive. I can try to simulate a noopener + close. But definitely, if the blobURL is opened in another process, this issue can be reproduced.
> It is a very commonly used technique to create a
> a[download][href="BLOB_URL"] to download a dynamically generated BLOB for
> normal web sites. How can it be "broken" and "odd" for addons?

Normally this works because the new link is opened by the same process. This assumption is not true when blobURL+download links are generated by addons.
Comment on attachment 8931841 [details] [diff] [review]
blobURL.patch

If we don't have any better approach, I'm OK with asking you to review this patch.

Note that I increased the timeout up to 5 seconds. This is needed for a debug build because, sometimes, spawning a new process takes more than 1 second. This is going to be a race condition anyway, but 5 seconds should be a timeout long enough.
Attachment #8931841 - Flags: review?(bugs)
Comment on attachment 8931841 [details] [diff] [review]
blobURL.patch

yeah, ok, not nice but don't have better ideas.
Attachment #8931841 - Flags: review?(bugs) → review+
Duplicate of this bug: 1379960
Is this gonna be a hotfix for 57 or people will have to wait for 58?

I'm getting bug reports for this issue every day now :(, and it seems like it's Linux / Mac only (I can reproduce it only in Ubuntu).
My add-on is GroupSpeedDial.
Pushed by amarchesini@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/bbb02c1fccd6
Postpone the removing of BlobURL for 5 seconds in order to allow the loading of them in a remote process, r=smaug
Pushed by amarchesini@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9e2680def2f9
nsHostObjectProtocolHandler::RemoveDataEntries can be called on any process, r=me CLOSED TREE
https://hg.mozilla.org/mozilla-central/rev/bbb02c1fccd6
https://hg.mozilla.org/mozilla-central/rev/9e2680def2f9
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
(In reply to Andrea Marchesini [:baku] from comment #9)
> > It is a very commonly used technique to create a
> > a[download][href="BLOB_URL"] to download a dynamically generated BLOB for
> > normal web sites. How can it be "broken" and "odd" for addons?
> 
> Normally this works because the new link is opened by the same process. This
> assumption is not true when blobURL+download links are generated by addons.

Why would it not be opened in the same process in the add-on case? Blob URIs should always be opened in the same process, by default (unless OOP extensions are disabled, anyway). I suppose the actual download should happen in the parent process, for the a[download] case, but we shouldn't be unloading the document in that case, either.
Depends on: 1423168
It seems that the actual issue is that the document unloads when it shouldn't be (bug 1423168).
This even happens if target=_blank.

Given that reason, the work-around is to avoid the main frame in the navigation to a blob:-URL, both in the source (the document where the <a> is placed) and the destination (the target attribute).
This can be done by placing the <a> in an <iframe> (possibly dynamically upon clicking a <a href=blob:...>).
Attached image Bug1420419 .gif
I can reproduce this issue on Firefox 55.0.3(20170824053622) under Win 7 64-bit and Firefox 57.0(20171112125346) and 58.0b9(20171204150510) Mac OS X 10.13.1

The options 1, 2 and 3 turns the web page into blank and the loading never completes.

This issue is verified as fixed on Firefox 59.0a1 (20171206100053) under Win 7 64-bit and Mac OS X 10.13.1.

All the 6 options are working..

Please see the attached video.
Status: RESOLVED → VERIFIED
(In reply to CosminB from comment #19)
> This issue is verified as fixed on Firefox 59.0a1 (20171206100053) under Win
> 7 64-bit and Mac OS X 10.13.1.
> 
> All the 6 options are working..

I can still reproduce issues on macOS (10.13.3) and Firefox 59.0b9 with open-blob-bug.zip:

- for options 1-3 the download of myfile.zip works correctly, but the test page turns blank.

- option 3: myfile.zip is downloaded although it should be myfile.txt as this is the value we set in the download attribute of the anchor. So the download attribute is ignored. You can also reproduce that by providing a Blob to URL.createObjectURL instead of a File. In this case the file name will be a random value.
Attached image Bug1420419.gif
I suspect that you can reproduce the issue on Mac OS X, because OOP is not turned on by default on Mac and Linux.

Could you please go to about:config, set the extensions.webextensions.remote preference to true, then to try again to reproduce the issue?

I could not reproduce your issue on Firefox 60.0a1 (20180218220057) under Mac OS X 10.13.2.

Please see the attached video.

Thanks!
Flags: needinfo?(thomas)
(In reply to CosminB from comment #21)
> Could you please go to about:config, set the extensions.webextensions.remote
> preference to true, then to try again to reproduce the issue?

I checked with 59.0b10 and options 1-3 work correctly when I switch extensions.webextensions.remote true.

Sorry, I'm failing to understand what is the status of this bug. By default extensions.webextensions.remote is set to false in 59.0b10 and 60.0a1 and therefore the bug is reproducible on macOS. Are there plans to switch extensions.webextensions.remote to true in the default profile and if yes, with which release?

Thanks.
Flags: needinfo?(thomas)
OOP is turned on by default only on Windows for Release, Beta and Nightly.
If I recall correctly, OOP still have rendering issues on Mac and Linux.

I think this is the reason why it was not switched on yet on Mac and Linux.

I think more info about this can be provided by the triage owner.

David, could you help me please with comment 22?

Thanks!
Flags: needinfo?(ddurst)
There are indeed still rendering issues on Mac and Linux, which is why OOP is not yet enabled.

I can't speak yet to which release, but I'm fairly certain that 61 would be the earliest.
Flags: needinfo?(ddurst)
Product: Toolkit → WebExtensions
Yes, I have the same problem since updating to "Quantum"  Tried everything. Mac OSX X High Sierra.
SeaMonkey works fine with addons / ad blocker and plays all videos.
Safari works, Opera works (again with ad blocker in place)
Firefox fails (same/ similar add ons). So Firefox IS the problem.  Did not go wrong prior to V 64.0
I have screen prints.

In the "Get Info", all other browsers show the "hidden" video in light grey, yet Firefox fails to show any video in its "Get Info" window.  This clearly indicates that Firefox refuses to load background video.
These are reference to my last comment. Many thanks.
Attached image site firefox.png
File 2 / Firefox
Same files in Sea Monkey / 1
Same files in Sea Monkey / 2 Examples are 'blob' video from youtube and brightcove (neither work in firefox)
Attached image site seamonkey.png
Same files in Sea Monkey / 2 (sorry previous one was duplicate).
Got it!  The problem is the "Tracking Protection"

I attach the screen print.  By default, the Tracking protection is always on.  I set it to "Only in private windows".  Also, the "Send web sites a "Do not Track"... I changed from "only when using tracking protection" to "Always".

So, it is none of the re-installing from scratch or other solutions, the video problem is in the tracking protection.
Attached image tracking protection.png
You need to log in before you can comment on or make changes to this bug.