Closed
Bug 380163
Opened 18 years ago
Closed 16 years ago
Run commandline handlers on Mac when the app is already running
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9.2a1
People
(Reporter: philor, Assigned: humph)
References
Details
Attachments
(1 file)
3.54 KB,
patch
|
jaas
:
review+
benjamin
:
superreview+
|
Details | Diff | Splinter Review |
On everything but Mac, whether or not the app is already running, "foo.exe http://example.org/" sends http://example.org/ through everything registered in the "command-line-handler" category, while on OS X we send it down the normal route if the app isn't running, and send it as window.arguments to a new browser.chromeURL window if the app is already running.
That screws up sending external URLs to full windows instead of limited popups for Firefox (bug 303568), and screws up sending URLs of RSS feeds to Thunderbird, which uses a message compose window for browser.chromeURL since it mostly expected mailto: URLs (bug 304704) and apparently doesn't work out well for ActiveState (bug 309212), and is certain to cause unexpected trouble for any extension that tries to do commandline handling, particularly if the author doesn't own a Mac.
Comment 1•18 years ago
|
||
I did something like this on the 1.8 branch for Thunderbird so Spotlight could run a thunderbird command line with the name of the .mozeml file to load. I really need this to work on the trunk at some point as well.
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
Assignee | ||
Comment 2•16 years ago
|
||
I am updating attachment 246624 [details] [diff] [review] for bug 290057 on trunk, and I was trying to test this last night by clicking an RSS feed in Safari. However, this never went through my code at all. I eventually tracked it down to how we deal with a file vs. url arg:
http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/xre/nsCommandLineServiceMac.cpp#435
My question is: what should we do with a url? Is it always right to pass the url through vs. opening a window, or is it also sometimes right to open it in a window?
Comment 3•16 years ago
|
||
I think we should never open a window and get rid of the very strange browser.chromeURL code. Instead, always go through command-line handlers with the -url <URL> argument. I'm not sure what we should do with files: perhaps pass them as -file <file>
Assignee | ||
Comment 4•16 years ago
|
||
Patch to follow-up work in http://hg.mozilla.org/mozilla-central/rev/c56446e2e61d. This might be too aggressive, but it works when tested in the ways described above.
Attachment #360194 -
Flags: superreview?(benjamin)
Attachment #360194 -
Flags: review?(joshmoz)
Attachment #360194 -
Flags: review?(joshmoz) → review+
Updated•16 years ago
|
Attachment #360194 -
Flags: superreview?(benjamin) → superreview+
Reporter | ||
Comment 6•16 years ago
|
||
Assignee: nobody → david.humphrey
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Hardware: PowerPC → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Reporter | ||
Comment 7•16 years ago
|
||
Comment on attachment 360194 [details] [diff] [review]
Remove OpenUrl, OpenWindow, use -url
Should be very minimal impact on Firefox (just making Mac act like every other platform when the app's running, the way it already does when the app isn't already running), and Tb3 really desperately needs it.
Attachment #360194 -
Flags: approval1.9.1?
![]() |
||
Comment 8•16 years ago
|
||
Could this possibly have caused bug 480733 ?
Reporter | ||
Updated•16 years ago
|
Attachment #360194 -
Flags: approval1.9.1?
You need to log in
before you can comment on or make changes to this bug.
Description
•