Closed
Bug 226612
Opened 20 years ago
Closed 20 years ago
-remote openURL no longer works with null URL.
Categories
(Core Graveyard :: X-remote, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.6beta
People
(Reporter: sgifford, Assigned: darin.moz)
Details
(Keywords: regression)
Attachments
(1 file, 2 obsolete files)
2.52 KB,
patch
|
bryner
:
review+
dbaron
:
superreview+
brendan
:
approval1.6b+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031122 Firebird/0.7+ Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031122 Firebird/0.7+ In earlier versions of Firebird, I could use: MozillaFirebird -remote 'openURL(,new-window)' to open up a blank new window. Now that gives an error, and starts up another copy of Firebird. As a work-around, I can use about:blank - MozillaFirebird -remote "openURL(about:blank,new-window)" but this change in behavior broke my toolbar link. Reproducible: Always Steps to Reproduce: 1.Start up MozillaFirebird 2.Run MozillaFirebird -remote "openURL(about:blank,new-window)" Actual Results: An error was printed, and a new copy of FB started up. Expected Results: A new blank Firebird window. It worked with FB0.6, and doesn't work with 20031122. I didn't notice it was broken until this last week, so it probably broke in a recent build.
Comment 2•20 years ago
|
||
Since darin says it's easy to fix, I want this bug to cover openURL(/tmp/foo,new-window) as well. (It should accept files without "file://" at the beginning.)
Component: General → X-remote
Product: Firebird → Browser
Version: unspecified → Trunk
Updated•20 years ago
|
Flags: blocking1.6b?
Assignee | ||
Comment 3•20 years ago
|
||
simple patch. check for empty aURL, and allow that. if loading aURL as a URI fails, then try creating a nsILocalFile from it. NOTE: nsLocalFile takes care of paths starting with "~/" and not just "/", which is good in this case.
Assignee | ||
Updated•20 years ago
|
Attachment #136344 -
Flags: superreview?(dbaron)
Attachment #136344 -
Flags: review?(bryner)
Assignee | ||
Comment 4•20 years ago
|
||
thanks to dbaron for catching my mistake in the previous patch. that would have caused thunderbird to try to load file:// URLs! :-( this patch solves that problem by reworking things so that we always call IsExposedProtocol.
Attachment #136344 -
Attachment is obsolete: true
Assignee | ||
Updated•20 years ago
|
Attachment #136344 -
Flags: superreview?(dbaron)
Attachment #136344 -
Flags: review?(bryner)
Assignee | ||
Updated•20 years ago
|
Attachment #136345 -
Flags: superreview?(dbaron)
Attachment #136345 -
Flags: review?(bryner)
Assignee | ||
Updated•20 years ago
|
Comment 5•20 years ago
|
||
Comment on attachment 136345 [details] [diff] [review] v1.1 patch This fixes the problems I was seeing and looks good to me, although I'm not sure if you want the unconditional return true on empty -- maybe it should be treated as about: because thunderbird might not want to handle the about protocol, i.e., if (aURL.IsEmpty()) scheme = "about"; // ':' needed?? else iso->ExtractScheme(aURL, scheme); ...
Attachment #136345 -
Flags: superreview?(dbaron) → superreview+
Assignee | ||
Comment 6•20 years ago
|
||
thanks again dbaron!
Attachment #136345 -
Attachment is obsolete: true
Assignee | ||
Updated•20 years ago
|
Attachment #136345 -
Flags: review?(bryner)
Assignee | ||
Updated•20 years ago
|
Attachment #136352 -
Flags: superreview?(dbaron)
Attachment #136352 -
Flags: review?(bryner)
Updated•20 years ago
|
Attachment #136352 -
Flags: superreview?(dbaron) → superreview+
Updated•20 years ago
|
Attachment #136352 -
Flags: review?(bryner) → review+
Comment 7•20 years ago
|
||
Don't forget to land this. :-)
Assignee | ||
Updated•20 years ago
|
Attachment #136352 -
Flags: approval1.6b?
Comment 8•20 years ago
|
||
Comment on attachment 136352 [details] [diff] [review] v1.2 patch a=brendan@mozilla.org for 1.6b. /be
Attachment #136352 -
Flags: approval1.6b? → approval1.6b+
Assignee | ||
Comment 9•20 years ago
|
||
fixed-on-trunk for 1.6 beta
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 10•20 years ago
|
||
This appears fixed in FB 20031130. Thanks for the fast work!
Updated•20 years ago
|
Flags: blocking1.6b?
Reporter | ||
Comment 11•20 years ago
|
||
I'm seeing pretty much this same bug again, although now instead of opening up a new window when I run: MozillaFirebird -remote 'openURL(,new-window)' it just displays an error: Failed to send command. As before, using: MozillaFirebird -remote "openURL(about:blank,new-window)" works just fine.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reporter | ||
Comment 12•20 years ago
|
||
This is in FB 20040114, trunk.
Reporter | ||
Comment 13•20 years ago
|
||
Looks like this is fixed in FB 20040119. Changing back to fixed.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Updated•5 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•