1482024 - New process spawning HTML file returns before running process reads file

Status: UNCONFIRMED

(Toolkit :: Startup and Profile System, enhancement)

Description

[martin f. krafft]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180510003646

Steps to reproduce:

Firefox is running. I have a HTML file, say `/tmp/index.html`. I want to open this file in the running process. So I run `firefox /tmp/index.html && rm /tmp/index.html` from the command line.

(Note: this is actually a simplification of what happens when I try to invoke Firefox on e.g. an HTML part from Mutt, via run-mailcap.)


Actual results:

In most cases, a tab opens saying that the file cannot be read. This is because the process I spawn from the command line (P1) only informs the running process (P0) of my desire to display the file, and then exits. In most cases, P0 will not have had a chance to read the file by the time P1 returns control to the parent process. In the above example, that's the shell, which then proceeds to invoke /bin/rm on the file. So by the time P0 wants to read the file, it'll often be gone.


Expected results:

The new process (P1) should wait until it gets the signal from P0 that the file has been read. This used to be the behaviour for years, but it's changed recently (around v57, I am not ready to swear on that).

Comment 1

[martin f. krafft]

Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887166

Comment 2

[martin f. krafft]

Here's a workaround for mutt: https://git.madduck.net/etc/mutt.git/commitdiff/76227d1c302ee76d82c037e923c70edc61fd5aea

Comment 3

[David Olah]

Hi Martin,

I tried to reproduce the issue and there are 2 cases that I tried on each version (Firefox 61.0, Firefox 60.1.0esr, Nightly 63.0a1 (2018-08-14) and Nightly 53.0a1 (2018-01-01)):

1. When Firefox is already opened and I run the command from Comment 0, the index file deletes and Firefox tab shows that the file is not found.
2. When Firefox in not opened and I run the commend from Comment 0, the index file is opened and only after closing Firefox the index file is being deleted.

These are the expected results from my point of view. I didn't manage to have different results on any version that I tried with the 2 above scenarios. 

Can you please try again and tell me if you identify 2 different behaviors with the same steps?

Comment 4

[martin f. krafft]

Hey David, sorry for the late response.

I see exactly the same behaviour, and I think both could be improved.

1. If a user invokes Firefox on a file, I think it's a reasonable assumption that the file has been consumed by the time control returns to the shell, because running "firefox ./index.html" is a statement "I want to view this file with Firefox", and the fact that the current asynchronous implementation of Firefox doesn't guarantee this behaviour should not be something the user has to worry about. The P1 firefox process should not return control to the invoking parent until it has been informed by the P0 process that the file has been read, which is the point when it can and should signal to the invoking user that the task it was asked to do has been completed.

2. Conversely, why should it be different when the user spawns up Firefox in the first place, to view a file? Why can't Firefox read the file, and fork to the background, which would be in line with the principle of least surprise, no? If users don't want this, wouldn't it make sense to ask them to pass `--foreground` to the process?

Thanks for your time,
martin

Comment 5

[David Olah]

I think it will be a good starting point if I will mark the issue as an Enhancement and set Content Processes component.

Comment 6

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

It looks like the “remoting” protocol (communication between the P1 and P0 processes in comment #0) includes waiting for a response message, at least in the X11 implementation, but internally there are a lot of synchronous interfaces that would need to be made asynchronous to delay the response until the document is loaded: at least nsRemoteService::HandleCommandLine, nsICommandLineRunner::Run, and nsICommandLineHandler::Handle.

I'm a little surprised that this ever worked (or at least that it ever would have worked reliably), because I thought Necko would open and read the file on a background thread, but it's possible that there's something I'm missing.

I'm going to send this to the bug component that owns toolkit/components/{remote,commandlines} because I think that's where most of the changes would need to be.