Closed Bug 82969 Opened 23 years ago Closed 23 years ago

mozilla -remote 'openUrl(URL)' does not work without new-window

Categories

(Core Graveyard :: X-remote, defect)

Product:
Core Graveyard
Component:
X-remote
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 41527
Milestone:
mozilla0.9.1

People

(Reporter: ajp+mozilla, Assigned: blizzard)

Details

(Whiteboard: critical for mozilla 0.9.1) 

This started happening sometime after the 0.9 release (not sure when) - 'mozilla
-remote COMMAND' used to work, e.g. 'mozilla -remote
"openUrl(http://www.mozilla.org)". Now, when running that commandline, mozilla
acts as if the command went through, with no error message, but the browser does
not open the specified URL. This also breaks programs such as gnome-moz-remote
and the GNOME URL handler.
After a -remote openurl fails: If you close (not quit) all visible mozilla
windows and a "ps -ef |grep moz" shows that mozilla-bin is still running, this
could be a variant of bug 82159
Nope, no mozilla processes running after closing.
I bet this is related to the window.open bug.  If I do mozilla -remote
"openURL()", I am presented with a dialog box to type in a URL.  However when I
dismiss the box, no page is loaded.  Also -remote openURL(something) has no
effect. -> XP Apps
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Even better.
Assignee: pchen → law
Component: XP Apps → XP Apps: Cmd-line Features
->mcafee?
Assignee: law → mcafee
yes, this seems to do a no-op now.  adding blizzard.

Yes, this has been screwed up some time in the recent past.
Assignee: mcafee → blizzard
Severity: normal → critical
Target Milestone: --- → mozilla0.9.1
Whiteboard: critical for mozilla 0.9.1
Just as a side note, I'm really surprised this hadn't been noticed much sooner -
I put off reporting it for at least a couple of weeks because I expected it to
be fixed or reported already - are we sure this isn't a dupe..?
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Woops.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 81793 has been marked as a duplicate of this bug. ***
This bug is a duplicate of 41527.
blizzard: can we resolve bug 41527 as a dup of this?
I don't think bug 41527 is related to this - 41527 deals with something about a
'current window' scenario, whereas this one causes -remote not to work completely.
Ari, if you take a closer look at the comments of this bug, you'll see that they
all talk about -remote openurl and nobody said what will happen if the
new-window option is used with openurl. In 41527 people went further and
realized that with the new-window option openurl will work correctly.
Summary: mozilla -remote does not work → mozilla -remote openURL does not work without new-window
Hm, indeed it does work with new-window.. Guess I can use that as a temporary
workaround.
Summary: mozilla -remote openURL does not work without new-window → mozilla -remote does not work
Summary: mozilla -remote does not work → mozilla -remote 'openUrl(URL)' does not work without new-window
Why is this critical for m91?  Is this the 99% case or the 1% case for all Linux
users of the codebase?
It's 99% of all users on Linux (and perhaps other platforms) who don't know that
specifying new-window as an argument will cause the bug not to show up.. This
also breaks a lot of other things in many UIs, such as GNOME's Mozilla url
handler and basically anything that depends on being able to open a URL in an
existing Mozilla process.
Actually, I'm marking this as a dup of 41527 and it is critical for 0.9.1. 
Everyone on linux uses mozilla this way.

*** This bug has been marked as a duplicate of 41527 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
Component: XP Apps: Cmd-line Features → X-remote
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.