270583 - protocol-handler for http still loads a Mozilla browser window

Status: RESOLVED INVALID

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Jeremy Hurst]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; INTRANETUSER)
Build Identifier: 

When you have the user preference "network.protocol-handler.external.http" set 
to true and you click on a link within a mail message, a Mozilla Browser window 
appears, then your external handler starts, but your Mozilla Browser remains on 
screen.

It should not even appear.

Reproducible: Always
Steps to Reproduce:
1. Set network.protocol-handler.external.http to true in your preferences file
2. Send yourself an email with a URL contained within it
3. Click on the link

Actual Results:  
The Mozilla Browser starts, then so does your external handler.

Expected Results:  
Only the external handler should have started, or at least the mozilla browser 
should have closed.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

mailnews opens the browser window itself, afaik, so changing product

Comment 2

[Jeremy Hurst]

When the functions are called to launch a new 'browser' window, it should be 
smart enough to detect the protocol being used an act accordingly. The fact is, 
we're telling Mozilla NOT to handle http.

Comment 3

[Mike Cowperthwaite]

Jeremy Hurst, which build of Mozilla are you using?

Comment 4

[Jeremy Hurst]

Sorry, I'm using Mozilla 1.7.3.

Comment 5

[[e-mail]]

Attachment: Proposed patch

Comment 6

[[e-mail]]

Comment on attachment 166705 [details] [diff] [review]
Proposed patch

Also includes JS strict warning fix.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 166705 [details] [diff] [review]
Proposed patch

changing request to darin who hopefully knows why isExposedProtocol didn't work
:-) (and whether it should work)

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

although I do note that ioservice has a method to extract a scheme name from a
string
(http://lxr.mozilla.org/seamonkey/source/netwerk/base/public/nsIIOService.idl#132)

Comment 9

[Jeremy Hurst]

Hi guys, whilst I don't profess to know the underlying code, albeit having a 
passionate desire to want to understand it, I fear one thing needs to be noted 
which is that if you are using a function call to search for the presense of, 
lets say 'http:', you need to be aware that some URLs may look like:

https://server.com/portalapp/proxy/http://internalserver/

In the case above, both https and http appear. Sorry, I don't want to tell you 
guys how to suck eggs, and that certainly is not my intention.

Comment 10

[Darin Fisher]

Comment on attachment 166705 [details] [diff] [review]
Proposed patch

Hmm... this works in thunderbird because http is not an exposed protocol, but
in seamonkey, http is an exposed protocol.

the suggested change does not seem quite right.  i suspect it would break
thunderbird, where we need to route clicks to non-exposed protocols (that may
have internal protocol handlers -- such as http!) through the external protocol
handler.

Comment 11

[[e-mail]]

Comment on attachment 166705 [details] [diff] [review]
Proposed patch

This file is not used by Thunderbird but should the requestor have to set
network.protocol-handler.expose.http preference to false?

Comment 12

[Jeremy Hurst]

There's been mention of Thunderbird and I know the products are very similar, 
but I am using Mozilla Mail. Just wanted to let you know in case it made a 
difference.

Comment 13

[Darin Fisher]

> This file is not used by Thunderbird but should the requestor have to set
> network.protocol-handler.expose.http preference to false?

Ah, ok.  Yes, setting that pref is probably better than setting the "external"
version since that forces inline http:// links to images and what not to be
loaded externally.  That can't be what anyone would want.  Look out, here comes
a flurry of SPAM!!!

The "expose" prefs indicate which protocols the mozilla product claims to be
able to handle when loaded via a link click, etc.  So, if you do not want HTTP
link clicks in Mozilla Mail to go to the Mozilla browser, then you should make
them not be exposed.  That will force them to be sent to ShellExecute.

So, perhaps this bug is invalid?  Or, do you want to revise the patch to only
cleanup the return codeS?

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

>that forces inline http:// links to images and what not to be loaded externally.

hmm, the patch seems to change an "onlick" function:
@@ -248,18 +245,19 @@ function messagePaneOnClick(event)
so, it is probably not executed for inline images.

Comment 15

[Darin Fisher]

biesi: if the URL string goes through nsIIOService, then the "external" pref
will cause the external protocol handler to be used.  that can't be what we want
for HTML content displayed inside the browser window.  in other words, we don't
want to break SPAM ;)

Comment 16

[Darin Fisher]

> for HTML content displayed inside the browser window.

for HTML content displayed inside the _mail message_ window.

Comment 17

[[e-mail]]

biesi, the point is that the jeremy's choice of preference affects all http
connections, which we think is wrong; he needs to use the link click pref.

Comment 18

[Darin Fisher]

Comment on attachment 166705 [details] [diff] [review]
Proposed patch

removing review requests

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

ah, yeah... nevermind me, then ;)

(note bug 270584 though, although that's probably invalid)

Comment 20

[Jeremy Hurst]

Hi guys,

Let me describe the problem again.

a) When you receive an email which contains a link, if you click on it, by 
default Mozilla Browser is loaded (irrespective of what the OS calls it's 
default browser). This should not occur, it should use the default browser if 
one other than Mozilla is used.

b) HTML messages should be displayed as HTML messages in Mozilla Mail

c) Inline images as part of an email should still be displayed inside Mozilla 
Mail as they do currently.

d) If the system is instructed to hand over http control to ShellExecute, it 
SHOULD NOT load up a Mozilla browser. Even though this browser doesn't do 
anything at the end of the day, it shouldn't appear in the first place.

e) With this setting in place, if you click Help > Release Notes you get your 
external handler AND a copy of Mozilla Browser. Again, just the external 
handler should load.

So... This bug is NOT INVALID - it IS a bug. No Mozilla Browser window should 
load AT ALL if you are telling Mozilla to not handle http.

The problem also extends to a number of function calls such as 
openTopBrowserWith() and openTopWin(), etc... they are all acting the same way.

Comment 21

[[e-mail]]

This bug is invalid. You should not be trying to disable the HTTP protocol
handler. Instead set network.protocol-handler.expose.http to false.

I don't know if release notes should launch in the default browser, but that's
outside the scope of this bug, so please don't reopen this one again.