From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020411 BuildID: 2002041103 Note:I'm not an experienced win32 developper. I've coded a small snippet that call ShellExecute() in win32 with a url. I was told this is the way to open a URL with the default browser, OR *with the browser currently running*. Here are the test cases I've tried: Case 1:IE is default browser. No browser running: Result 1: Calling ShellExecute starts IE on the url specified. Statisfying: yes Case 2:IE is default browser. Opera is running. Result 2: Calling ShellExecute opens a new window in the running Opera. Statisfying: yes Case 3:IE is default browser. Mozilla is running. Result 3: Calling ShellExecute starts IE on the url specified. Statisfying: NO. Reproducible: Always Steps to Reproduce: 1.Make IE your default browser 2.Start Mozilla (no other browser started) 3.Call ShellExecute with a url Actual Results: Opens IE to display the url. Expected Results: Should use mozilla to display the url since it is running. You can also have step 3 above done without coding: just do "start menu->run" and type in a URL (http://google.com). Some technical explanations : http://www.wd-mag.com/articles/1997/9708/9708d/9708d.htm?topic=articles http://support.microsoft.com/default.aspx?scid=kb;en-us;Q283225 (I could not find the actual documentation @ MS) I don't know what the behavior is supposed to be when more than one browser is running. Also, I have no clue if this actually works when moz is the default browser. The actual code I used is (from memory) : ShellExecute(whndl,"open","http://google.com",NULL,NULL,0); I can do additionnal testing an supply more info if needed.
I've also experienced the same behavior in win98 (different but recent build).
-> XP APPS
Assignee: Matti → sgehani
Component: Browser-General → XP Apps
QA Contact: imajes-qa → paw
Additionnal testing: I've redone all tests with RC1 on win98: nothing change. Additionnal tests done: Case 4:Moz is default browser. No browser running: Result 1: Calling ShellExecute starts moz on the url specified. Statisfying: yes Case 5:Moz is default browser. Mozilla is running. Result 3: Calling ShellExecute starts moz on the url specified. Statisfying: yes (Creates a new window: I like that.) Case 6:Moz is default browser. Opera is running. Result 2: Calling ShellExecute starts moz on the url specified. Statisfying: NO (but not that bad ;) ) Case 7:Moz is default browser. IE is running: Result 1: Calling ShellExecute starts moz on the url specified. Statisfying: NO (but not that bad ;) )
The behaviour you're seeing is correct. ShellExecute is always supposed to launch the application associated with the string you pass to it (whether it determines the correct application by file extension or protocol or whatever). If the application is already running, ShellExecute can send a DDE message to the application to load the document, rather than spawning a new copy. I really don't understand quite how Opera takes over control when running - maybe it makes itself the default browser while it's open, maybe it pretends to be IE and intercepts DDE messages. While it might be useful, it's not correct. Mozilla is registering itself correctly in the registry, and you're seeing what I would expect. To summarise: The browser that should open a window when you call ShellExecute with a URL is the one that is registered for the protocol (the 'default browser'). None other.
Ok, I agree with the comment #4. Did some more test and when moz is default and IE is running, moz is started. So, since IE does not steal the url when running, I don't think moz should either ;) I was mislead by opera doing it and by the comment in the first article saying : "ShellExecute() is smart enough to start the default browser if it is not running, or just instruct the currently running browser to go to the desired URL." Maybe this should have read "instruct the currently running *default* browser". Can I mark this bug as INVALID since I'm the reporter anmd I'm happy with the explanation?
Invalid per user's comments
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.