Closed Bug 192849 Opened 23 years ago Closed 22 years ago

[Mach-O] Mozilla, on receiving URL from another application while shut down, launches and displays blank page rather than URL

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: Shawn.Vrabel, Assigned: ccarlen)

References

Details

Attachments

(1 file)

patch
1008 bytes, patch
lordpixel
: review+
sfraser_bugs
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030211 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030211 Clicking on links in Mail.app or typing "open http://mozilla.org" will open Mozilla but will not open the link. Reproducible: Always Steps to Reproduce: 1.Quit Mozilla. 2.Click on link in Mail.app 3.Observe nothing happening. Actual Results: A blank browser window appeared. Expected Results: Opened the browser and loaded the page.
*** Bug 194039 has been marked as a duplicate of this bug. ***
-> XP Apps & confirming Also, I can't imagine this has only been reported one other time, I just couldn't find another dupe on my searching
Assignee: asa → jaggernaut
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: asa → paw
Whiteboard: DUPEME
*** Bug 194307 has been marked as a duplicate of this bug. ***
*** Bug 193944 has been marked as a duplicate of this bug. ***
*** Bug 194491 has been marked as a duplicate of this bug. ***
*** Bug 195349 has been marked as a duplicate of this bug. ***
*** Bug 195646 has been marked as a duplicate of this bug. ***
*** Bug 195719 has been marked as a duplicate of this bug. ***
Basic functionality flaw. Block 1.3?
Flags: blocking1.3?
Whiteboard: DUPEME
*** Bug 195779 has been marked as a duplicate of this bug. ***
Revising summary.
Summary: [Mach-O] Browser does not open URLs from other applications on first load → [Mach-O] Mozilla, on receiving URL from another application while shut down, launches and displays blank page rather than URL
not gonna hold 1.3 for this. Hopefully 1.4a
Flags: blocking1.4a+
Flags: blocking1.3?
Flags: blocking1.3-
*** Bug 197532 has been marked as a duplicate of this bug. ***
*** Bug 197725 has been marked as a duplicate of this bug. ***
*** Bug 198332 has been marked as a duplicate of this bug. ***
Flags: blocking1.4a+ → blocking1.4a-
*** Bug 200268 has been marked as a duplicate of this bug. ***
*** Bug 197650 has been marked as a duplicate of this bug. ***
*** Bug 200747 has been marked as a duplicate of this bug. ***
*** Bug 200946 has been marked as a duplicate of this bug. ***
Going on two months now and this still hasn't been assigned. Can we please get this fixed?
thank you for volunteering to fix this
Assignee: jaggernaut → jgleigh
Well, I don't have a fix, but I think I might have narrowed this down a little. This is my first time touching Mozilla source code, so be gentle if I'm off-base ;) In nsNativeAppSupportForCocoa.mm, there is a bunch of code for dealing with the splash screen which is commented out because the splash screen doesn't actually work in MachO. If I uncomment that code, then the 'open location' event that causes Mozilla to launch works (even though no splash screen is displayed, since the splash screen stuff is actually broken). With it commented out, it doesn't. This seems to imply to me that the initial "process any pending events the system sent us as we launched" code must be tied into the splash screen somehow...
Dave, nsNativeAppSupportForCocoa.mm isn't used in any working build. That file is only compiled in toolkit=cocoa builds. Mach-O mozilla isn't built with cocoa.
OK... /me wonders what the hell else was different between my two builds then, since I did get it to work once...
Some apps will dispatch URLs to Mozilla that don't work (they are old-style CFM urls). Give us an example of one that breaks for you.
$ cat - | osascript tell application "MozillaDebug" open location "http://www.google.com/" end tell ^D Works fine if Mozilla is already running. If Mozilla wasn't running and has to launch, it doesn't work (you get your default home page instead of the one specified in the script).
(Related to bug 197643?)
We get to here: http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsAppRunner.cpp#1220, and processedArgc == 3 (nsCommandLineServiceMac is putting the url into the command line properly) and defaultStartup == FALSE. Something goes wrong after that point. This seems like a pretty major usability issue. Taking.
Assignee: jgleigh → ccarlen
Attached patch patch — — Splinter Review
Adding a url string to the command line without the "-url" arg doesn't work.
Comment on attachment 119701 [details] [diff] [review] patch I could have sworn this file had been detabbed. Oh well, I'd like to detab it on this checkin.
Attachment #119701 - Flags: superreview?(sfraser)
Attachment #119701 - Flags: review?(lordpixel)
Another thing I noticed when working on this: While Camino gives the option of what to do when asked to open a URL (new window, new tab, etc.), not mozilla. Am I missing something?
Attachment #119701 - Flags: superreview?(sfraser) → superreview+
No, but we could add it to Mozilla.
That might be bug 121969.
tested patch locally, it works. :)
Attachment #119701 - Flags: review?(lordpixel) → review+
Fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 203804 has been marked as a duplicate of this bug. ***
*** Bug 203140 has been marked as a duplicate of this bug. ***
*** Bug 206139 has been marked as a duplicate of this bug. ***
*** Bug 207297 has been marked as a duplicate of this bug. ***
*** Bug 232461 has been marked as a duplicate of this bug. ***
Fine, that the bug should be fixed but when I install Mozilla from an official page and this bug is still apparent and nothing is to be found in the actual bug thread I would guess that some clever individuals know how to avoid this problem but fixing would imply to my understanding to change sourcecode to avoid this bug. Sorry for this arrogant comment but I am no expert and even reading all the comments and threads which eventually inform me how to correct the problem myself is too much for leisure time or weekend. If this problem is ***really*** solved as a compiled actual version I would be greatful to get a note. bye dirk
Dirk: note that this bug is resolved/fixed. The issue in question was fixed on 2003-04-08, which would have made it into every build since 1.4ish. What version are you using that it's still broken in?
I have had this problem repeatedly with Eudora. Reinstalling Eudora fixed the problem every time. This might indicate that the problem is not always with Mozilla.
Yes, I would agree in that case. I use Eudora myself. Eudora doesn't use the standard system mechanism for launching a URL (which is what got fixed here). Eudora has its own hack of a system for doing it (which "happens" to work with most browsers). Eudora's a nice powerful client, but its authors have a habit of fighting Apple tooth and nail against any change they ever make to the operating system. (See their comments in the "Internet Dialup" settings panel for an example). They also tend to publicly blame Apple for many of their bugs, when really it means they didn't follow the docs when they originally wrote it.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: