1469348 - Cannot download the PDF file successfully from google drawings

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[Nathan Froyd [:froydnj]]

[Tracking Requested - why for this release]: would be nice if the google office suite worked as expected.

STR (sort of, see below):

1. Navigate to https://docs.google.com/drawings/d/1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY/edit?usp=sharing

This is a Google drawing document.

2. Attempt to print using the platform-specific shortcut of your choice.  (The webpage overrides the shortcut.)

ER:

A PDF is downloaded, to which the drawing in question has been printed, and the browser offers for you to open it.

AR:

This apparently depends on the platform.

On my wife's Mac, release Firefox, the PDF begins to download, but gets stuck about halfway through.  When you cancel it, the downloads box says the thing that was trying to be downloaded was some kind of blob resource.

On my Mac, nightly Firefox, nothing starts to download.  The browser console contains alarming messages like:

Attempting to post a message to window with url "resource://pdf.js/web/viewer.html" and origin "resource://pdf.js^userContextId=1" from a system principal scope with mismatched origin "[System Principal]".
_getLoginDataFromParent: A form origin is required
offsetParent is not set -- cannot scroll viewer.js:2007:5
PDF 7c81c1cae73ba3e70087fffa8afb81c2 [1.4 - / Google] (PDF.js: 2.0.581) viewer.js:1087:7

On my Linux machine, nightly Firefox, nothing starts to download.  The browser console contains a little bit more detail from LoginManagerContent:

 [Show/hide message details.] XHRGET
https://docs.google.com/drawings/d/1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY/export/pdf?id=1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY&pageid=p
[HTTP/2.0 200 OK 149ms]
LoginManagerContent: onStateChange handled: <unavailable> LoginManagerContent.jsm:112
LoginManagerContent: _onNavigation: state: <unavailable> loginFormRootElements approx size: 0 document: <unavailable> LoginManagerContent.jsm:892
LoginManagerContent: Created non-form FormLike for rootElement: <unavailable> LoginManagerContent.jsm:1637
LoginManagerContent: adding <unavailable> to loginFormRootElements for <unavailable> LoginManagerContent.jsm:1641
LoginManagerContent: onDOMInputPasswordAdded: <unavailable> <unavailable> LoginManagerContent.jsm:397
LoginManagerContent: Creating a DeferredTask to call _fetchLoginsFromParentAndFillForm soon LoginManagerContent.jsm:401
LoginManagerContent: Arming the DeferredTask we just created since document.readyState == 'complete' LoginManagerContent.jsm:422
LoginManagerContent: Created non-form FormLike for rootElement: <unavailable> LoginManagerContent.jsm:1637
LoginManagerContent: adding <unavailable> to loginFormRootElements for <unavailable> LoginManagerContent.jsm:1641
LoginManagerContent: _detectInsecureFormLikes https://docs.google.com/drawings/d/1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY/edit LoginManagerContent.jsm:493
LoginManagerContent: Running deferred processing of onDOMInputPasswordAdded <unavailable> LoginManagerContent.jsm:408
LoginManagerContent: _detectInsecureFormLikes https://docs.google.com/drawings/d/1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY/edit LoginManagerContent.jsm:493
LoginManagerContent: Couldn't parse origin for blob:https://docs.google.com/a99391e1-f765-4975-8372-d9fe2f8742f8 <unavailable> LoginManagerContent.jsm:1404
Attempting to post a message to window with url "resource://pdf.js/web/viewer.html" and origin "resource://pdf.js^userContextId=1" from a system principal scope with mismatched origin "[System Principal]".
_getLoginDataFromParent: A form origin is required
offsetParent is not set -- cannot scroll viewer.js:2007:5
PDF 7c81c1cae73ba3e70087fffa8afb81c2 [1.4 - / Google] (PDF.js: 2.0.581) viewer.js:1087:7
[Show/hide message details.] XHRPOST
https://docs.google.com/drawings/d/1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY/logImpressions?id=1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY&token=AC4w5Vjtgu-xSgkhgOIJVocHeTDxSYU8pA%3A1529340774173&ouid=109496284273041333033&includes_info_params=1
[HTTP/2.0 204 No Content 87ms]

On my Mac, Firefox 57, printing does not work.

On my Mac, Firefox 52, printing works fine; I get a popup box asking me if I would like to open a PDF, and the PDF contains a printed version of the document.  The source is "blob:", for whatever that's worth.

Unsure if this is a site issue, our issue, a PDF.js issue, or what.  Would be nice to get this fixed for 61, but there's probably zero time left for that.  Filing it here for initial triage, and ni?'ing RyanVM, since we were talking about this over IRC, and he has some results on different platforms.

Comment 1

[Liz Henry (:lizzard)]

Tracking this for 62 as it is too late to get a fix into the 61.0 release. 
When I try to print from Nightly (62) from MacOS 10.13.5, nothing starts to download.

Comment 2

[Liz Henry (:lizzard)]

Marking this fix-optional for 62. If anyone lands a fix and thinks it is safe for uplift to beta 62, you can still request uplift.

Comment 3

[Alphan Chen [:alchen]]

Attachment: content handling setting

Comment 4

[Alphan Chen [:alchen]]

(In reply to Nathan Froyd [:froydnj] from comment #0)
> AR:
> This apparently depends on the platform.
> 
> On my wife's Mac, release Firefox, the PDF begins to download, but gets
> stuck about halfway through.  When you cancel it, the downloads box says the
> thing that was trying to be downloaded was some kind of blob resource.
> 
> On my Mac, nightly Firefox, nothing starts to download.  The browser console
> contains alarming messages like:
>  
> On my Linux machine, nightly Firefox, nothing starts to download.  The
> browser console contains a little bit more detail from LoginManagerContent:
> 

The different behaviors are caused by the different settings of content handling.
You can check attachment 8998878 [details].

If you choose "save file", we will see the pdf is downloading.
However, the symptom is the same as you found.
We cannot complete the download.

Comment 5

[Alphan Chen [:alchen]]

(In reply to Alphan Chen [:alchen] from comment #4)
> 
> If you choose "save file", we will see the pdf is downloading.
> However, the symptom is the same as you found.
> We cannot complete the download.

The PDF can be downloaded completely in the end.
I will try to find out the reason for this symptom.

Comment 6

[Rares Doghi, Desktop QA]

Hi, I tried to get a regression range on this issue but it goes back as far as possible, including 52.

Command + P will not start to Print or give the user the possibility to save as a PDF file since the "Print" prompt is not displayed.

I can however go to File > Print > save as PDF in all versions of Firefox, and another way that seems to work is if I Open the Dev  Tools with Fn+F12 and then  hit Command + P, this seems to cause the Print pop-up window to be displayed.

Comment 7

[Alphan Chen [:alchen]]

Attachment: The window of "Web Developer->Network"

Request URL is https://docs.google.com/drawings/d/1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY/export/pdf?id=1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY&pageid=p.

The File just cannot be downloaded successfully. (264.93KB /265.55KB)

Comment 8

[Alphan Chen [:alchen]]

Attachment: http-log

Here is the "http log" which records the process.

Comment 9

[Alphan Chen [:alchen]]

To narrow down the variables of this symptom, I set the handling of PDF file as "save file".

We can reproduce the symptom on Mac.
The PDF can be downloaded successfully on Win10 and Ubuntu.

Comment 10

[Alphan Chen [:alchen]]

Hi Kershaw,
could you take a look on the attachment 8999181 [details]?

Comment 11

[Alphan Chen [:alchen]]

(In reply to Alphan Chen [:alchen] from comment #5)
> (In reply to Alphan Chen [:alchen] from comment #4)
> > 
> > If you choose "save file", we will see the pdf is downloading.
> > However, the symptom is the same as you found.
> > We cannot complete the download.
> 
> The PDF can be downloaded completely in the end.

Actually, the download cannot complete at that time.
The completion I saw is the result of cancel first and re-try.

Comment 12

[Kershaw Chang [:kershaw]]

(In reply to Alphan Chen [:alchen] from comment #10)
> Hi Kershaw,
> could you take a look on the attachment 8999181 [details]?

From networking point of view, everything looks fine.
The http channel opened for downloading is finished without error. In addition, the size of the file also looks correct.

Comment 13

[Alphan Chen [:alchen]]

I found the problem is caused by this check.
https://searchfox.org/mozilla-central/source/netwerk/base/BackgroundFileSaver.cpp#673
Assume that it is related to the file name.
Will dig deeper.

Comment 14

[Alphan Chen [:alchen]]

(In reply to Alphan Chen [:alchen] from comment #13)
> I found the problem is caused by this check.
> https://searchfox.org/mozilla-central/source/netwerk/base/
> BackgroundFileSaver.cpp#673
> Assume that it is related to the file name.
> Will dig deeper.

In the end, it is not related to the file name.
On Mac, the address of mRenamedTarget and mActualTarget are not the same.
In my opinion, we should use "nsLocalFile::Equals" to do the compare.
I will submit a patch with the modification.

Comment 15

[Alphan Chen [:alchen]]

Attachment: Bug 1469348 - Fix the problem of download file failed on Mac. r=paolo

Comment 16

[Alphan Chen [:alchen]]

Comment on attachment 9000172 [details]
Bug 1469348 - Fix the problem of download file failed on Mac. r=paolo

Hi Paolo,

Could you take a look on this patch?

On Mac, we don't get the same address of mRenamedTarget and mActualTarget.
However, they point to the same file.
So I use "nsLocalFile::Equals" to do the check.
Does it make sense to you?

Comment 17

[:Paolo Amadini]

I've commented in the review. This issue probably existed since bug 809752. Thanks again for debugging it!

Comment 18

[:Paolo Amadini]

Uh? That should've been bug 920017.

Comment 19

[:Paolo Amadini]

(And attachment 809752 [details] [diff] [review].)

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Is there a Try build available that I can test with Windows?

Comment 21

[Alphan Chen [:alchen]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #20)
> Is there a Try build available that I can test with Windows?

Not yet.
Besides, there is one more problem of this bug.

Comment 22

[Alphan Chen [:alchen]]

Hi Paolo,

this bug also point to another symptom:
 If we choose the action for PDF to "Preview in Nightly", we cannot open the pdf by firefox(pdf.js?) successfully.
This symptom can be reproduced on Mac/Windows/Ubuntu.
Any idea about this?

Comment 23

[:Paolo Amadini]

As discussed on IRC, worth filing a separate bug. Thanks!

Comment 24

[Alphan Chen [:alchen]]

(In reply to :Paolo Amadini from comment #23)
> As discussed on IRC, worth filing a separate bug. Thanks!

Rename this bug title and file bug 1483900 for PDF preview.

Comment 25

[:Paolo Amadini]

Can you write a quick summary of the issue for the detailed commit message?

(I don't think our current review tool supports reviewing that directly from the patch, but that should be put in the patch description.)

Comment 26

[Alphan Chen [:alchen]]

In this bug, we will focus on the problem of cannot download PDF file from google drawing successfully on MAC.

After investigating, I found that "SetTarget()" is called twice with two different addresses.
However, they both point to the same file.
We will assign the first target to "mInitialTarget" and the second one to "mRenamedTarget".

This problem happened when doing the second "SetTarget()".
After canceling the existing AsyncCopy, we will schedule a new AsyncCopy.
However, we only assign the mActualTarget with mRenamedTarget when they point to different files.
In this case, the two different addresses point to the same file.
So the mActualTarget is still the same as mInitialTarget.

After completion of the AsynCopy, we try to do "CheckCompletion".
But it will always return false due to "mRenamedTarget exists" and "mActualTarget" is not the same as "mRenamedTarget".

The solution is quite easy.
We should always update mActualTarget with renameTarget, even if they point to the same file.

Comment 27

[:Paolo Amadini]

Thanks! That's a very clear commit message, and the comments you added in the patch also help.

Comment 28

[:Paolo Amadini]

Comment on attachment 9000172 [details]
Bug 1469348 - Fix the problem of download file failed on Mac. r=paolo

:Paolo Amadini has approved the revision.

Comment 29

[:Paolo Amadini]

I actually thought I had already approved the revision before writing comment 25, but the comments and status changes were only drafts, and I had to click "Submit" in the review tool to make them public, which I apparently didn't do.

Sorry for that, it wasn't my intention to block the review on the commit message!

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1906a8b16d63
Fix the problem of download file failed on Mac. r=paolo

Comment 31

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/1906a8b16d63

Comment 32

[Rares Doghi, Desktop QA]

Hi, I reproduced this issue in Older versions of Firefox Nightly, but I can no longer reproduce this issue in Firefox Nightly 63.0a1 (2018-08-21), I will mark this issue as Verified.

Comment 33

[Ryan VanderMeulen [:RyanVM]]

Seems like a pretty simple fix. Did you want to request Beta/ESR60 uplift on it? It grafts cleanly as-landed.

Comment 34

[Alphan Chen [:alchen]]

Comment on attachment 9000172 [details]
Bug 1469348 - Fix the problem of download file failed on Mac. r=paolo

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: A simple fix with notable effect
User impact if declined: Cannot download file successfully on some websites
Fix Landed on Version:Firefox 63
Risk to taking this patch (and alternatives if risky): N
String or UUID changes made by this patch: N

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Approval Request Comment
[Feature/Bug causing the regression]: No
[User impact if declined]: Cannot download file successfully on some websites
[Is this code covered by automated tests?]: No
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]: No
[List of other uplifts needed for the feature/fix]: No
[Is the change risky?]: No
[Why is the change risky/not risky?]: Simple fix
[String changes made/needed]: No

Comment 35

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9000172 [details]
Bug 1469348 - Fix the problem of download file failed on Mac. r=paolo

Fixes broken downloads from a major website. Approved for 62.0b20 and ESR 60.2.

Comment 36

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/809eb582affd

Comment 37

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr60/rev/b7142243310c

Comment 38

[Rares Doghi, Desktop QA]

After further investigation on Mac OS X 10.13 and 10.12 with Firefox Nightly (2018-08-22) I found out that if the user reaches https://docs.google.com/drawings/d/1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY/edit?usp=sharing and Clicks File > Print > Save as PDF the file downloads correctly, but if I press the CMD + P shortcut - nothing happens and then Go to File > Print,  An Error message : "The page at resource://pdf.js says: Warning: The PDF is not fully loaded for printing." 

Please note that the file saved as PDF is still fully downloaded.

I could also download the file from https://docs.google.com/drawings/d/1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY/export/pdf?id=1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY&pageid=p.

Following these steps I can reproduce the same Warning message in Nightly 62.0a1(2018-06-01) but the file still downloads correctly.

Based on these results, please note that I can't reproduce this issue with a build that does not have the fix.

I did a screen recording of this issue please see the following link: https://streamable.com/oeuuh

Please take a look.

Comment 39

[Alphan Chen [:alchen]]

Attachment: platform-specific shortcut

Comment 40

[Alphan Chen [:alchen]]

Attachment: Cannot Complete Download

Comment 41

[Alphan Chen [:alchen]]

(In reply to Rares Doghi from comment #38)
> Based on these results, please note that I can't reproduce this issue with a
> build that does not have the fix.
> 
> I did a screen recording of this issue please see the following link:
> https://streamable.com/oeuuh
> 
> Please take a look.

What you did is a different behavior.
The problem we met is like attachment 9003389 [details].
In the video, we don't see the ongoing download.

Please do the test by the following steps:
1. Set the setting as attachment 8998878 [details]
2. Navigate to https://docs.google.com/drawings/d/1nIis2eowQFvpv0rwBCXS0dHg9NpCqk5xGM3uQyNEJYY/edit?usp=sharing
This is a Google drawing document.
3. Attempt to print using the platform-specific shortcut(attachment 9003388 [details])

Comment 42

[Rares Doghi, Desktop QA]

Thanks a lot for these Steps, I was able to reproduce the issue in Firefox Version 62.0b19 but no longer in Firefox version 62.0b20, I also managed to reproduce in Firefox 60.1.0esr which no longer reproduces in Firefox 60.1.1esr as well as Nightly 62.0a1(2018-06-01) but no longer reproduces in the Latest Nightly 63.0a1 (2018-08-22).

Here are the builds that I used to Confirm this issue as Fixed:

BETA:
https://tools.taskcluster.net/index/gecko.v2.mozilla-beta.latest.firefox/macosx64-opt

ESR:
https://tools.taskcluster.net/index/gecko.v2.mozilla-esr60.latest.firefox/macosx64-opt

I will mark this issue Verified as Fixed for those versions as well.