Closed Bug 181454 Opened 22 years ago Closed 22 years ago

Multiple windows opened following load request from another application

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: wagner, Assigned: sfraser_bugs)

References

Details

Attachments

(1 file)

Patch to nsMacCommandLine to fix the problem
1.18 KB, patch
ccarlen
: review+
jag+mozilla
: superreview+
asa
: approval1.3b+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021120
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3a) Gecko/20021120

in 10.2.2, when this build of moz is instructed to activate and open and URL by
another application (typically, M$ Entourage), it activates and loads the page.
the problem is it loads the page over and over again, presumably consuming
resources until crash. moz is barely responsive when it is in this "loop loading
page" state. i can close windows but another will replace it as soon as i do. i
can Quit moz with repeated CMD-Q attempts and i can force quit it. will verify
and comment as to whether this is just Entourage or other applications as well

Reproducible: Always

Steps to Reproduce:
1. click on an URL embedded in Entourage/other application that is to launch
browser and open said URL
2.
3.

Actual Results:  
moz repeatidly opened externally requested URL over and over in new windows

Expected Results:  
open the externally requested URL in a single, new window

i am using tabbed browsing on a vanilla install of moz (i download the latest
trunk each morning). this just cropped up recently in the past several days. i
am using classic theme with no icons. build ID listed in moz windows is
2002112008 (it is, assuming intentionally, truncated above)
1. verified that it happens with external URL requests from other applications.
opened Terminal, typed in an URL and CMD-clicked it

2. after CMD-Q out of Terminal requested loop, activated >THIS< URL from within
Entourage to add these comments. this caused moz to launch and open this url
without the loop issue. re-tested this by quitting moz and re-clicking on this
URL from within Entourage

3. closed all windows in moz and attempted to activate same URL in Entourage.
page loading loop ensued. only seems to NOT happen when moz is not running and
is lanuched on external request
Summary: infinite loop during page load from external trigger → infinite loop during page load from external request
Confirmed using FizzillaCFM/2002112208. I command+clicked a URL in
MT-NewsWatcher and Mozilla kept opening new windows to display it. I had to
force-quit Mozilla.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: infinite loop during page load from external request → Multiple windows opened following load request from another application
FWIW, this also occurs on MacOS 9.0.4 (build ID#2002112208), so you might want
to change the OS field to All.  Any url launched from another application or
from a URL file in the Finder opens in window after window.

I don't really understand any of this, but this is an Apple Event problem,
right?  I've noticed some bugs have their summaries flagged with [Apple Events]
(for example: bug 181868 ).  Should this bug?
Changing OS to Mac System 9.x per comment 3 (it isn't downgraded to port status
yet, so this is the correct setting).

Possibly Event Handling? Let's try that first.
Assignee: asa → saari
Component: Browser-General → Event Handling
OS: MacOS X → Mac System 9.x
QA Contact: asa → rakeshmishra
OK, I was experiencing this bug too, and then I tried opened the Internet Pref
Pane, and changed the linkage from 1.2b to 1.3a (the nightly) and the bug
_seems_ to have been squashed. Can anyone else try this?

Ken
The problem is still evident to me using FizzillaMach/2002112507 after ensuring
it's selected in Internet Prefernces.
if it is happening in FizzillaMach then we should make the platform OSX so it
gets more love
Hmmm. Why is this listed as a 9.x bug in the OS field? (Don't understand Greg's
explanation re "downgraded to port status".)

The orig report talks about OSX (althought there is a reference in Comment 3 to
9.0x). I for one experienced this in 10.0.2, although (see comment 3) it seems
to have been self-squashed by changing my Internet browser prefs in the pref
pane. (Oh, also installed Orbit Retro skin, fwiw).

K
klanda@mac.com, the OS field is supposed to indicate the oldest OS version under
which the problem is evident. Since the problem has been seen in OS X and OS 9,
the OS field is set to OS 9.

(Of course OS X and OS 9 are a lot more different than just a major version
number. The current configuration of Mac system versions in Bugzilla leaves much
to be desired, but in its' present state this bug is set correctly.)
Well, I tried pinning down when this bug first popped up.  As far as I can tell,
the last nightly trunk build in which this does not occur is 2002111515. 
Unfortunately, there's a big gap of time in which there aren't any non-OS X Mac
nightlies; the next one I found (I won't guarantee that I didn't miss any),
2002111908, exhibits this problem.  Hope that's at least a little bit helpful.

One other observation: this problem only occurs when Mozilla is already running.
 If Mozilla isn't open, and you, say, double-click on a URL in the Finder,
Mozilla will launch and open the URL in only one window, like it's supposed to.
 Don't know how relevant that is.
re: klanda@mac.com  [internet pref pane selection]

i verified that my selected browser is moz 1.3a in my internet prefs pane/web
and it still happens with the latest build (2002112908)

interesting thing is when i attempt to manually choose the newly installed moz
instead of using the pop-up menu in the internet prefs pane, nothing seems to
happen after navigating to and selecting the application. i end up with a blank
in the selected web browser

fwiw, i only have moz 1.3a in my internet pref pane web browser selection. IE
isn't on my machine
Has anyone who knows what they're doing checked Bonsai between 11-15 and 11-19
to   figure out what checkin screwed this up?  To my non-programmer eyes, the
checkins for bug 111797 and bug 179932 look somewhat suspicious, but then I
don't understand these things.

I realize I'm not being very helpful, and I don't want to nag.  I'm just afraid
that this will become harder to fix the more time that passes.  Moreover, since
there may be a OS X workaround*, I'm a little worried that fixing this for OS 9
will be seen as a low priority and put off indefinitely.

*For the record, I got access to an OS X system, hoping to pinpoint more
precisely when this bug first appeared.  I wasn't able to reproduce the bug at
all.  I suspect that this could be due to the fact the system had IE as it's
default browser so I had to change it.  Following comment 5, that may have
prevented the problem.  I don't know.  I can say that no analogous workaround
works with recent OS 9 builds.
long ago i had trouble getting my browser pref to stick in the internet control
panel pane in osx. i took the advice of a osxhints tip and created a disk image
and moved the explorer application bundle into it and then left the disk image,
unmounted, in the Applications folder. i could then mount it on the off chance
that i would need to use exploder for something. until then IE didn't enter into
the picture at all as far as my os was concerned and moz would remain my
preferred browser.

see above in my comment #11 where i said i could not, in the internet control
panel pane, navigate to the moz application icon and end up with anything
showing as selected. today i mounted my IE disk image and went back to the
internet cp pane where i found IE and Moz 1.3a listed in the pop-down menu of
browers to choose from. instead of choosing either of those, i navigated to my
current moz build and selected it. it stuck. i quit moz and unmounted the IE
image, essentially removing it from the system. 

now moz 1.3a is showing up as selected in the internet cp pane. there are no
other choices but that at this point (with the ie disk image unmounted). things
seem to be working ok now in regards to external links not infinite looping on
open. it's not a real fix i guess, but it's great as far as i'm concerned. this
bug was driving me (and my workstation) nuts! :) 
Wagner One, that comment is irrelevant to this bug. Please refrain from adding
irrelevant comments to bug. If you can't find an appopriate bug to comment on,
you might try end-user forums such as those on MozillaZine.org.
Flags: blocking1.3a?
Flags: blocking1.3a? → blocking1.3a-
*** Bug 186245 has been marked as a duplicate of this bug. ***
*** Bug 188522 has been marked as a duplicate of this bug. ***
*** Bug 187854 has been marked as a duplicate of this bug. ***
*** Bug 184668 has been marked as a duplicate of this bug. ***
*** Bug 187978 has been marked as a duplicate of this bug. ***
*** Bug 187681 has been marked as a duplicate of this bug. ***
*** Bug 187400 has been marked as a duplicate of this bug. ***
*** Bug 184110 has been marked as a duplicate of this bug. ***
Thanks for marking my dupe, Torben. Another probable dupe is bug 185950.

*** Bug 185950 has been marked as a duplicate of this bug. ***
This bug needs more attention, Mozilla cannot in practice be used as default
browser on macs because of this. Changing OS to MacOSX since nobody cares about
Mac classic anymore and requsting blocking for 1.3b.
Flags: blocking1.3b?
OS: Mac System 9.x → MacOS X
We should definitely figure out if this can be fixed for beta. Saari, is this
something you can look into? If not then who?
Flags: blocking1.3b? → blocking1.3b+
in dagley's absence, ->sfraser
Assignee: saari → sfraser
nsMacCommandLine::DispatchURLToNewBrowser was returning errAEEventNotHandled,
even if we did handle the event. The patch sets err to noErr if the
OpenWindow() call succeeds.
Comment on attachment 113047 [details] [diff] [review]
Patch to nsMacCommandLine to fix the problem

The file has tabs; I'll fix the spacing before checkin.
Attachment #113047 - Flags: superreview?(jaggernaut)
Attachment #113047 - Flags: review?(ccarlen)
Comment on attachment 113047 [details] [diff] [review]
Patch to nsMacCommandLine to fix the problem

r=ccarlen
Attachment #113047 - Flags: review?(ccarlen) → review+
Comment on attachment 113047 [details] [diff] [review]
Patch to nsMacCommandLine to fix the problem

sr=jag
Attachment #113047 - Flags: superreview?(jaggernaut) → superreview+
Comment on attachment 113047 [details] [diff] [review]
Patch to nsMacCommandLine to fix the problem

a=asa (on behalf of drivers) for checkin to 1.3beta.
Attachment #113047 - Flags: approval1.3b+
Yeeee hah! A big thank you to the Mozilla team for fixing this. As soon as the
patch goes live I'll start using nightlies again (I've been sticking with 1.2.1). 

Bug 184363 (Destroy All Tooltips, remake of an excellent B movie) is still a
pain, but I'll live with it.

Frankie, thanks for your offer for testing help. It is likely that this patch
will land today which means that tomorrow's builds should have the fix. If you
can get that build as soon as possible tomorrow, test this problem and report
back to this bug that would be a great help. (and that tooltip crasher is going
to be fixed shortly as well). 
Checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Sadly, the nightly latest Mac is still 20020122. No successful builds in over a
week?

Also, latest Macho 20020130 doesn't run for me, but that's probably because I
didn't RTFM.

How come the "nightly" links on mozilla.org still point to CFM builds that
aren't even being built?
cfm bits have been renamed on moz.org. Asa and I are working on fixing the links
on the home page
*** Bug 176124 has been marked as a duplicate of this bug. ***
Although I understand that this bug is resolved, I haven't tested it yet.
However I think it maybe useful to record an observation I just made about it.

After I have the repeating windows and kill Mozilla, the start up time
was terribly long.  I just discovered that Mozilla leaves huge files in
the cache, named _CACHE_001_*

Apparently handling these causes the startup to be slow, since when I deleted
them it started up very quickly.  (As an aside startup on a Sun is
terribly slow and so is window closing; if folks think this is a separate
bug I could report it as so.)
*** Bug 192883 has been marked as a duplicate of this bug. ***
*** Bug 192650 has been marked as a duplicate of this bug. ***
*** Bug 195474 has been marked as a duplicate of this bug. ***
v
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: