1600413 - [macOS] Opening file URIs from the CLI strips hash/query information from the URL

Status: RESOLVED INVALID

(Core :: Widget: Cocoa, defect, P3)

Description

[theshadow]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Attempt to open a PDF on the local disk to a specific page.

open -a "Firefox" --args -url 'file:///path/to/file.pdf#page=10'
open -a "Firefox" --args -url 'file:///path/to/file.pdf?pageNumber=10'

Actual results:

The PDF is opened but the page information is stripped opening the PDF to the first page.

Expected results:

It should open the PDF to the correct page so that we can use hypermedia links from other tools.

Comment 1

[theshadow]

Command correction:

open -a "Firefox" 'file:///path/to/file.pdf#page=10'
open -a "Firefox" 'file:///path/to/file.pdf?pageNumber=10'

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:bdahl, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Brendan Dahl [:bdahl]]

This also happens with file uris and html pages. I'm moving components since it's not specific to the PDF viewer.

Comment 5

[:Gijs (he/him)]

This works fine on Windows. I expect we're normalizing URLs through some apple API and it throws away the query/hash bit. Certainly by the time any frontend / commandline handling code sees it, those bits are gone, so fixing this is going to need to happen at an earlier point in time.

Comment 6

[Stephen A Pohl [:spohl]]

Haik, I vaguely remember you working on sanitizing URLs a while back. Did this apply to launching Firefox from the command line as well, or was that unrelated?

Comment 7

[Haik Aftandilian [:haik]]

(In reply to Stephen A Pohl [:spohl] from comment #6)

Haik, I vaguely remember you working on sanitizing URLs a while back. Did this apply to launching Firefox from the command line as well, or was that unrelated?

Yes, for bug 1722758 (and follow up fix bug 1737854). NSURL is more strict about which characters must be encoded in each portion of the URL so we have to manually encode some characters before passing them to [NSURL URLWithString]. I don't know if that's happening here and can see Safari has the same behavior for the file:/// example I tested. I'll leave the needinfo while I look into this.

Using the --args option to the open command does continue to work. I think this bug is specifically about when --args is not used and the open command treats the argument as a URL. Per the open man page, "If the file is in the form of a URL, the file will be opened as a URL."

Comment 8

[Haik Aftandilian [:haik]]

This is a bug with the macOS open(1) command in how it handles file URLs. Specifically, the macOS open command recognizes file:/// arguments as URLs (as described in the man page) but removes the URL fragment and query string components before passing them to the target application on the command line. One can check the arguments passed to Firefox and see the problem using the $ ps -ef command after Firefox has been launched. The problem is not specific to Firefox and occurs with Safari and Chrome too.

As a workaround, pass the URL to Firefox directly using the --args option to open. For example,

$ open -a Firefox --args 'file:///path/to/file.pdf#page=10'

I've reported this to Apple as Feedback Request FB9954398 "/usr/bin/open Command Drops URL Fragment (and other components) from file:/// URLs".