Bug 180704 - [GTK] Document files don't download
Summary: [GTK] Document files don't download
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: All Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 184942 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-12-12 11:01 PST by bugzilla-ok
Modified: 2020-06-26 06:32 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bugzilla-ok 2017-12-12 11:01:21 PST
Website https://ccfs.sos.wa.gov . . . login, "Notices and Filed Documents", "View Documents"

Progress bar travels across top of window then stops. Nothing happens.

In Firefox, pdf file is downloaded and dialog requests what should be done with it.

Inspect element of "View Documents":

<i class="fa fa-file-text-o fa-lg ng-binding ng-isolate-scope ng-scope" style="cursor:pointer" filename="document.CorrespondenceFileName" params="document" url="Common/DownloadOnlineFilesByNumber?fileName=&amp;CorrespondenceFileName=&amp;DocumentTypeId=" title="Download" download-file="" ng-bind="document.CorrespondenceFileName" ng-click="downloadPdf()"></i>
Comment 1 Michael Catanzaro 2018-04-24 12:38:04 PDT
My guess is that you probably have the evince browser plugin installed; can you confirm? Check in about:plugins in Epiphany.

If so, you'll need to report it against Evince on GNOME Bugzilla.

If not, then we're going to need some reproducer on a public website.
Comment 2 bugzilla-ok 2018-04-24 16:14:26 PDT
It was installed so I removed it. The problem continues whether or not the plugin is installed.

Same problem with MiniBrowser and Surf.

Surf debug says, "curl: (3) Port number ended with 'h'"
Comment 3 Michael Catanzaro 2018-04-24 18:20:10 PDT
(In reply to bugzilla-ok from comment #2)
> It was installed so I removed it. The problem continues whether or not the
> plugin is installed.
> 
> Same problem with MiniBrowser and Surf.
> 
> Surf debug says, "curl: (3) Port number ended with 'h'"

Wow... I'm sure somebody has reported this before. I wonder what the explanation is for that.

Obviously the load is going to fail if the port number is invalid... the real question is: why on Earth is there an h in the port number? :)
Comment 4 bugzilla-ok 2018-04-24 21:51:45 PDT
Yes, it seems like a clear problem. But confusing because other browsers (eg firefox, qupzilla, etc) have no problem with it. If the problem is an "h" that doesn't belong, maybe it can be stripped?
Comment 5 Michael Catanzaro 2018-04-24 21:57:12 PDT
*** Bug 184942 has been marked as a duplicate of this bug. ***
Comment 6 Michael Catanzaro 2018-04-24 21:58:48 PDT
I don't think so. Very very very few websites use custom port numbers. If the website puts an 'h' in the port number, it seems pretty fair to expect the load to fail.

That said, I'm sure we've seen this error once before. I just don't remember where or why. Is it possible you reported this before in the past? (Not bug #184942.)
Comment 7 bugzilla-ok 2018-04-24 22:16:52 PDT
Here's the script corresponding to the download button that isn't working:

<i class="fa fa-file-text-o fa-lg ng-binding ng-isolate-scope ng-scope" style="cursor:pointer" filename="document.CorrespondenceFileName" params="document" url="Common/DownloadOnlineFilesByNumber?fileName=&amp;CorrespondenceFileName=&amp;DocumentTypeId=" title="Download" download-file="" ng-bind="document.CorrespondenceFileName" ng-click="downloadPdf()"></i>

No sign of the website putting an "h" in the port number. Maybe surf is reporting the problem inaccurately? Or maybe the "h" is inserted from somewhere else.

I had this same problem with surf-2 logging an an "h" in the port number but closed the bug because the sites were all private. In this case, while the specific login is private, the site itself is public. Maybe you can replicate?

The bug began with epiphany using WebKit2 but worked fine in Webkit1. Something must have changed. Any ideas what to check next?
Comment 8 Michael Catanzaro 2018-04-25 06:21:10 PDT
We need to see the implementation of downloadPdf() to know what it's doing.

The site looks private to me. Can you tell me how to download a file without logging in? (Even if it's possible, we normally do not debug websites without assistance from the developers of the website, but I could take a quick look.)
Comment 9 bugzilla-ok 2018-04-25 12:52:28 PDT
>We need to see the implementation of downloadPdf() to know what it's doing.

The button script isn't what you want? I'm not sure what you're asking for here.

As for downloading a file without logging in, I'm not aware of a way. Sorry about that. I encounter bugs but can't give you access to see them yourself! I totally understand your difficulty. Maybe you could get access from the administrators or create an account yourself? In this case, it's a state agency.
Comment 10 Michael Catanzaro 2018-04-25 12:58:11 PDT
We don't have time to debug individual websites, sorry.

downloadPdf() is a JavaScript function implemented somewhere by that website. We can't even begin to guess why it's trying to download an invalid URI without being able to see it.
Comment 11 bugzilla-ok 2018-05-13 16:42:02 PDT
Would you like to close the bug as too difficult to solve under the circumstances? I'm willing to run tests for you if it would help.
Comment 12 bugzilla-ok 2018-05-16 15:24:17 PDT
Behavior has changed! The PDF file now downloads as expected.

Almost as expected. It downloads to disk and is opens in evince rather than being views directly in Epiphany using the browser-plugin-evince plugin. Other sites view pdf files using the plugin, as expected.

I wonder, is the download/view in browser/open external behavior configurable at all?
Comment 13 Michael Catanzaro 2020-06-26 06:32:47 PDT
(In reply to bugzilla-ok from comment #12)
> I wonder, is the download/view in browser/open external behavior
> configurable at all?

No. Nowadays it should always use pdf.js.