Closed Bug 1141439 Opened 5 years ago Closed 5 years ago

Command line handling errors are not properly reported back through Xremote

Categories

(Core Graveyard :: X-remote, defect)

All
Linux
defect
Not set

Tracking

(firefox39 fixed)

RESOLVED FIXED
mozilla39
Tracking Status
firefox39 --- fixed

People

(Reporter: glandium, Assigned: glandium)

References

Details

Attachments

(2 files)

A command line handler can throw an NS_ERROR_ABORT, which is reported back as an error code when there is not an already running Firefox.

Example STR:
- Take current nightly
- Install the attached addon
- Quit Firefox
- In a terminal, run "firefox -foo", then "echo $?", that gives 1.
- Start Firefox normally
- In a terminal, run "firefox -foo"

Expected result:
- Same as when Firefox was not running: it terminates and the exit code is 1.

Actual result:
- A "Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system." popup, and an exit code of 0.
Attached file clh.xpi
Blocks: 1141441
Comment on attachment 8575134 [details] [diff] [review]
Exit with an error code instead of falling through the REMOTE_NOT_FOUND code path when the X-remote returns an explicit command line handler error

I'm even more confused now that I asked the question about this code in the other bug.
Attachment #8575134 - Flags: review?(benjamin) → review+
https://hg.mozilla.org/mozilla-central/rev/772e07ff4eba
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.