Open Bug 1560997 Opened 4 months ago Updated 3 months ago

Custom schema fails intermittently with "The address wasn't understood"

Categories

(Firefox :: File Handling, defect, P3)

67 Branch
Desktop
Windows 10
defect

Tracking

()

UNCONFIRMED

People

(Reporter: stuart.coope, Unassigned)

Details

Attachments

(3 files)

Attached file bind-notpad.reg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Using Windows 10, set up a custom handler for a schema (see bind-notepad.reg)

Create a sample web page with the following link:

<a href="notepad://foo">Notepad</a>

Browse to it and click the link. Accept launching the link in notepad and remember that preference.

Actual results:

It works most of the time but by opening the page in a new tab, it sometimes fails with the following error:

The address wasn't understood

Firefox doesn't know how to open this address, because one of the following protocols (notepad) isn't associated with any program or is not allowed in this context.

You might need to install other software to open this address.

I've created a video demonstrating the fault: https://huddlestrong-my.sharepoint.com/personal/stuart_coope_huddle_com/_layouts/15/onedrive.aspx?id=%2Fpersonal%2Fstuart%5Fcoope%5Fhuddle%5Fcom%2FDocuments%2Fnotepad%2Dcustom%2Dschema%2Emp4&parent=%2Fpersonal%2Fstuart%5Fcoope%5Fhuddle%5Fcom%2FDocuments&cid=9024c0f1-363e-40a4-8ebc-bdd2c22d558d

Expected results:

notepad.exe should open all the time. A message about the filename being incorrect is expected.

OS: Unspecified → Windows 10
Hardware: Unspecified → Desktop

Hi Stuart,

I tried to open the link you send us but it asks me for Microsoft credentials. Can you please attach a video to this ticket or to another website with sharing permissions?

I understand that the expected result should be clicking on the link and notepad has to open with the word "foo", correct? could you please share a sample page with the link so we can test it on our end?

Thank you for your report and regards

Flags: needinfo?(stuart.coope)
Flags: needinfo?(stuart.coope)
Attached file open_notepad.html

Hi,

Thanks for getting back to me. Sorry about the link not working. I've now attached the video directly to this ticket.

As seen in the video, notepad launches successfully the first three times. On the fourth attempt, we see it fail with "The address wasn't understood".

Expected behaviour is that notepad opens 100% of the time. It is expected that we see an error (within notepad) about the path not being understood. This is expected as the argument after the schema is used as the filepath to open and "foo" is not valid. Hopefully that makes sense.

I've attached the HTML file I used to recreate this (just a link using the custom schema).

Best,
Stuart

Hi Stuart,

Thanks for the video and for the information.
I'll add a product and component so the devs can take a look at this.

If you consider this is not the right product/component please feel free to change it.

Regards,

Component: Untriaged → Networking
Product: Firefox → Core

I think the component should be Firefox:File Handling.
Feel free to correct me if I am wrong.

Component: Networking → File Handling
Product: Core → Firefox

Honza, do you know what's going on here? The description of the bug makes it sound like maybe we're starting a content process for a new tab load and we don't initially know about external protocols in the new child process, but that's a bit surprising in that from a quick look at the code, in e10s all these loads get diverted to the parent anyway. The external protocol handler code is technically assigned to this bugzilla component, but understanding what's happening here seems like it requires some netwerk expertise... :-(

Flags: needinfo?(honzab.moz)

I think this has nothing to do with the channel diversion.
When the link(notepad://foo) is clicked, we call SendLoadURIExternal from child process and nsExternalHelperAppService::LoadURI will be called in parent process.

(In reply to Kershaw Chang [:kershaw] from comment #8)

I think this has nothing to do with the channel diversion.
When the link(notepad://foo) is clicked, we call SendLoadURIExternal from child process and nsExternalHelperAppService::LoadURI will be called in parent process.

So why would it fail intermittently? :-\

Somebody has to reproduce this locally and either use (or add) logging or simply debug this.

Flags: needinfo?(honzab.moz)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.