Open Bug 499785 Opened 11 years ago Updated 9 years ago

SeaMonkey can't handle spaces in OpenURL, Firefox can

Categories

(SeaMonkey :: Startup & Profiles, defect)

x86
Linux
defect
Not set
trivial

Tracking

(seamonkey2.1 wontfix)

ASSIGNED
Tracking Status
seamonkey2.1 --- wontfix

People

(Reporter: bunk, Assigned: neil)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1pre) Gecko/20090622 SeaMonkey/2.0b1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1pre) Gecko/20090622 SeaMonkey/2.0b1pre

firefox and seamonkey already running.

$ firefox -remote 'OpenURL(http://www.google.com/asdf asdf)'
$ seamonkey -remote 'OpenURL(http://www.google.com/asdf asdf)'

Firefox opens "http://www.google.com/asdf asdf"
Seamonkey opens "http://www.google.com/asdf"

I have some memory that it was documented somewhere that spaces in OpenURL don't work, but considering that Firefox supports it it would be nice to get this functionality copied into Seamonkey.

Reproducible: Always
This bug can hit you e.g. when doing Social Bookmarking from Liferea.

In practice, whatever Firefox supports is what gets used by applications.

Please check whether that's something that could easily be ported from Firefox for Seamonkey 2.0 .

Thanks in advance
Flags: wanted-seamonkey2.0?
Neil, can you take a look at this? It _might_ be easy, depending on how URLs are handled there...
Summary: SEamonkey can't handle spaces in OpenURL, Firefox can → SeaMonkey can't handle spaces in OpenURL, Firefox can
The regexp we use currently allows "http://www.google.com/asdf new-tab" (or new-window) when it should require a comma.
Attached patch Possible patch (obsolete) — Splinter Review
[Bah, -remote doesn't work on initial startup. It really ought to just allow startup to continue as normal, but still open the remoted URL.]
Assignee: nobody → neil
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #401693 - Flags: review?(bugzilla)
(In reply to comment #4)
> [Bah, -remote doesn't work on initial startup. It really ought to just allow
> startup to continue as normal, but still open the remoted URL.]
Conveniently it does work on Windows, if I launch the build I just patched...
(In reply to comment #4)
> Created an attachment (id=401693) [details]
> Possible patch
> 
> [Bah, -remote doesn't work on initial startup. It really ought to just allow
> startup to continue as normal, but still open the remoted URL.]

That patch regresses heavily for me:

With this patch even
  seamonkey -remote 'OpenURL(http://www.google.com/asdf)'
(the normal non-space case) now opens an empty new window instead of the requested page in a new tab.
Attached patch Try thisSplinter Review
I accidentally omitted a ? :-(
Attachment #401693 - Attachment is obsolete: true
Attachment #401697 - Flags: review?(bugzilla)
Attachment #401693 - Flags: review?(bugzilla)
(In reply to comment #7)
> Created an attachment (id=401697) [details]
> Try this

Thanks, works for me.
Flags: wanted-seamonkey2.0? → wanted-seamonkey2.0+
Severity: enhancement → trivial
Can anyone review the patch, and apply it if it is considered OK?

Thanks in advance
Flags: wanted-seamonkey2.1?
Component: General → Startup & Profiles
QA Contact: general → profile-manager
Flags: wanted-seamonkey2.1?
mcsmurf! Please check your review queue!
Neil, can you check the patch for bitrot and make sure it still does as you want, I'll review for you. But we (sadly) cannot get this into 2.1 now.
You need to log in before you can comment on or make changes to this bug.