166872 - URLs from 3rd party apps-->Mozilla passing URL as "1"

Status: VERIFIED FIXED

(Core Graveyard :: Cmd-line Features, defect)

Description

[Allen Castaban]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

You need to have a Yahoo account with mail and Yahoo Messenger 5.5 installed to reproduce this.  Whenever you try to go to Yahoo Mail account by clicking on the Messenger window buttons, the resulting Mozilla window have a 1 in the location bar and consequently it does not reach to Yahoo Mail login page as 1 is not a valid URL
This was working with 1.0 RC2.

Reproducible: Always

Steps to Reproduce:
1.Start Mozilla
2.Start Yahoo Messenger 5.5
3. In the Messenger window click on the little bell icon at the bottom
4. In the resulting window click on "0 New Messages"
5. Observe the new Mozilla window with a 1  in location bar
6. Observe Mozilla failing to reach the login page

Actual Results:  
Cannot login to Yahoo Mail from the Messenger

Expected Results:  
I should be directed to Yahoo Mail login page, was working with 1.0 RC2

Comment 1

[James "Dexter" Akula]

This is certainly the case with NS7, though not always.  Often, it works just
fine.  Moreover, if you use IE6 (maybe any IE, I don't know) as your default
browser, Yahoo! Messenger asks you the first time if you want to be
automatically logged in.  This is a nice feature on a home PC where security
isn't an issue.  Get the new mail popup, glick "Go to Yahoo! mail!" and voila,
you're at your inbox.

Comment 2

[Max Kanat-Alexander]

That's a pretty good bug report. Problem is, it's now November! This bug has
another vote, so it might actually be a problem still. (However, I'll bet that
it's only lying around in NS7, which means that it should be reported at Netscape.)

Could you please download a recent nightly build from
<ftp://ftp.mozilla.org/pub/mozilla/nightly/>, and then let us know if you 
still see this problem?

Thanks,

M

Comment 3

[Daniel Wang]

*** Bug 179604 has been marked as a duplicate of this bug. ***

Comment 4

[Nicholas Bebout ([e-mail] is my new email)]

Could you try a nightly build?  If it doesn't exist in a nightly build, please
resolve this bug as WORKSFORME.

Comment 5

[PAPO]

Currently using Mozilla 1.3a {Build ID 2002113004} .I have reproduced the
problem and the bug was killed! Mozilla works perfect! Nice job!

Comment 6

[Allen Castaban]

The problem still exist for 1.2, I don't know 1.3a

Comment 7

[PAPO]

Hey guys I wanna apologize for my fake alarm , but unfortunately the problem
came up again today using Mozila 1.3a .The scenario slightly different , I had a
prompted window from Y Messenger notifying me that a new mail arrived  , clicked
on the windows.and there was again the 1 in the address bar. Afterwards I did
the same steps as the bug guide indicates and still the same resutls.Yesterday
it workd..reproducing the bug steps!

Sorry for my false comment!

Comment 8

[benc]

-> networking for analysis. thanks to dwx for finding the dupe.

Comment 9

[benc]

*** Bug 182254 has been marked as a duplicate of this bug. ***

Comment 10

[Susie Wyshak]

Shouldn't this be assigned to a networking engineer?

Comment 11

[Susie Wyshak]

-->dougt

FYI I can still replicate this on 11/13 trunk, but not in any branch builds.

Moving comment that Darin made in the duped bug:
------- Additional Comment #4 From Darin Fisher  2002-12-03 08:55 -------

dougt: bug 179026 was fixed on 11/11, and bug 181732 was fixed on 11/25.  hmm..
not sure that either of these could be related, but it might be worth
investigating.  are you setup to try backing these out?

Comment 12

[Doug Turner (:dougt)]

wfm today's trunk build.  Also, a debug from last night worked fine.  marking WFM.

Susie, could you try todays build (2002-12-03-08-trunk)

Comment 13

[Susie Wyshak]

Yay - wfm also with 12-3 trunk.

Comment 14

[Susie Wyshak]

I'm reopening this. It happened today with the same Gecko/20021203 trunk build
that worked yesterday.

Should I ask Yahoo to test this? I'm wondering if they use different servers and
maybe one is configured wrong somehow. Thoughts?

Comment 15

[Susie Wyshak]

And now I am able to replicate this 100% of the time (3 of 3 tries this morning,
whether I am logged in or am not logged into Yahoo mail at the time of
attempting to access it via the alert icon)

Comment 16

[Susie Wyshak]

Good news - Spoke to Yahoo. It's a Yahoo issue that they will fix.

Comment 17

[Allen Castaban]

As the original reporter of this problem, I like to point out that this was working with 1.0 RC2. So it is unlikely it is a Yahoo problem

Comment 18

[Allen Castaban]

I have some additional info.  This just happened to me with Windows Messenger.
Symptom is the same, 1 in the location bar. But the way you reproduce is different. Select Tools->Options and click on Help. You will see a 1 in the location bar. This makes it very, very unlikely it is a Yahoo problem.
Then I did some more testing. To make IE my default browser, I uninstalled Mozilla. Then clicked on Windows Messenger Help and it worked in IE.  Then I installed it Mozilla back and tried again, bingo it worked.  It will break again, I am sure, as since I reported this I did many re-installs. But I don't know what breaks it. Again I sincerely doubt that this is a Yahoo (and now W. Messenger) problem.

Is there any way, like a debug or trace tool, to tell whether Mozilla is passed the right URL or not, outside of looking at the location bar?

Comment 19

[Susie Wyshak]

Thanks. I will see if Yahoo can tell me if they've seen this with other browsers.

If not I will flip this back to engineering.

cc'ing dougt

Comment 20

[Susie Wyshak]

-->Browser
I have seen this behavior with another application trying to click a URL to a
Mozilla branch build so tentatively suggesting it's networking?

Comment 21

[Allen Castaban]

I too have seen this with a lot of other applications, which again suggests it
has nothing to do with Yahoo Messenger

Comment 22

[Doug Turner (:dougt)]

is this or is this not a yahoo problem?    Give me a test case please.

Comment 23

[Susie Wyshak]

Emailed Doug with some more info. Allen it would be interesting to know which
apps and builds you saw this with.

Comment 24

[Allen Castaban]

This has been happening to me since 1.0 release (Worked with 1.0 RC2). I only
work with released versions. It happened to me with 3 applications Yahoo
Messenger, Windows Messenger and a 3rd one (which one, I don't remember).

Comment 25

[Susie Wyshak]

Changed subject from: Cannot login to Yahoo Mail using Yahoo Messenger

to
URLs from 3rd party apps-->Mozilla pass URL as "1"

Comment 26

[benc]

Maybe an engineer could comment on how this mechanism works? My assumption is
that we are signed up as any number of protocol hanlders in the OS, including
http, so when some else's app sends an HTTP URL to the OS, it goes to us.

If that is the case, then setting IE to the system default browser, and then
doing the same steps, would at least tell us what URL people are being sent to.

maybe there are OS tricks that would show us what is being called, maybe a
poorly formated URL string?

Comment 27

[benc]

based on comments, clearing milestone and setting version to trunk, asking for
1.3b blocker status.

I think we need to figure out what is going on here.

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We would not hold the 1.3beta release for this.

Comment 29

[Judson Valeski]

minusing for topembed. this *appears* to be application specific (mozilla's not
handling the os event properly), and doesn't affect embedding applications. if
we're wrong, please re-nominate.

Comment 30

[Doug Turner (:dougt)]

until i get a reproducible case, I can not fix this.  this currently wfm windows
2k 1.3b.

Comment 31

[Ernest Cline]

Bug 179083 is similar to this one. Only difference is that the desired page does
get loaded. Should that bug be folded into this one?

Comment 32

[Andrew Schultz]

behavior here is consistent with bug 95977, but I have no idea what the
mechanism here.

Comment 33

[Doug Turner (:dougt)]

to darin.

Comment 34

[Mothra]

I have repeated this with the 3rd party app Rosetta Resolver
[which unfortunately I doubt many people can use ($$$$)] using
the 1.3 release:
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3) Gecko/20030312

Mozilla correctly handles the url request the first time when it
is started up.  Subsequent links passed via the same mechanism try
to open the url "1".  The url I am passing uses user@pass authentication
in the url.

Comment 35

[Susie Wyshak]

I'm curious: If you look at the source code is there an extra return between the
a and href for the link that breaks?

I noticed in another app that is embedding Gecko that the URLs that break have
an extra space which is why I'm asking. 


P.S. I am still seeing this problem 100% of the time with Yahoo Messenger mail
notification and current trunk builds.

Comment 36

[Mothra]

I only see this behavior for "long" URLs where I cannot
explicitly define long but for example a mozilla bug link
(http://bugzilla.mozilla.org/show_bug.cgi?id=166872) is short,
while something like 

http://host.domain.com/cgi-bin/directory/x.cgi?x=parameter&
&q=select+distinct+field_1,field_2,fd_name,fd_type,field_3+from+the_whole_boat+w
here+field_1+in+(select+another+from+elsewhere+where+another+in
('ID001','ID002','ID003','')

is long.  Short URLs always seem to work correctly.  Another behavior
is that the long URL seems to open a new Mozilla window instead of trying 
to open the URL in an existing browser, as happens with short URLs.

Comment 37

[James "Dexter" Akula]

This bug is very annoying.  I think it should block 1.4, since it can't be that
hard to figure out.

Comment 38

[buggeriam]

James and other people that are seeing this -- is this only happening on windows 2k?

Comment 39

[Mothra]

I see it on Windows NT 4.0

Comment 40

[Johny]

And WinXP - SP1 for me with Moz 1.3.

Comment 41

[Doug Turner (:dougt)]

There is a bug in the DDE handling.  I tracked it down to
HandleDDENotification() and ParseDDEArg() in nsNativeAppSupport.  

Comment 42

[Susie Wyshak]

I'm nominating this to block 1.4. 

Comment 43

[Doug Turner (:dougt)]

spoke to bill yesterday, he is not working on this.  over to samir.

Comment 44

[Doug Turner (:dougt)]

Attachment: Strawman patch

oh well.  this bugged me too much to pass it onto the apps team.

Completely reproduceable with this test case:

#include <windows.h>
#include <shellapi.h>

const char* url = \
"http://example.com/abc/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/test.html";


int main()
{
    ShellExecute(NULL, "open", url, NULL, NULL, SW_SHOWNORMAL);
    return 0;
}

The problem is that DdeCreateStringHandle() only supports 255 chars.  In the
above example, we pass something like 260.  The result is undefined.  

I have a patch which does "fix" this bug, but I am not sure it is completely
correct.  Basically, I don't understand why we create a string handle at all in
this context.  It may be that we don't have to at all, and we can simply use
the value returned by DdeAccessData().	

attached is the strawman patch.  This patch also includes some string cleanup.

Comment 45

[(not reading, please use [e-mail] instead)]

giving to doug.

or doug, was it your idea to hand off the patch?

Comment 46

[Doug Turner (:dougt)]

Attachment: closer to fine. v.1

Took bill law's suggestion and created a new ParseDDEArgs that takes a (const
char*) as the first param.

Comment 47

[Darin Fisher]

Comment on attachment 122224 [details] [diff] [review]
closer to fine. v.1

>Index: nsNativeAppSupportWin.cpp

>+                    nsCString windowID;
>+                    ParseDDEArg(hsz2, 0, windowID);

nsCAutoString not cool here?


>+void nsNativeAppSupportWin::ParseDDEArg( const char* args, int index, nsCString& aString) {
>+
>+    if ( args ) {

style / consistency nit.  kill extra newline.


>+    return;
>+}

nit: function returns |void|, so why not kill the extraneous |return|
statement?


>+void nsNativeAppSupportWin::ParseDDEArg( HSZ args, int index, nsCString& aString) {
...
>+    nsCString temp;

nsCAutoString?	wouldn't hurt i think.


>+    // Ensure result's buffer is sufficiently big.
>+    temp.SetLength( argLen + 1 );

"+1" not required.  string API requires SetLength to allocate null byte if
appropriate (in this case it is appropriate since nsCString is always null
terminated).


sr=darin with these nits fixed.

Comment 48

[(not reading, please use [e-mail] instead)]

Comment on attachment 122224 [details] [diff] [review]
closer to fine. v.1

a=sspitzer

thanks dougt, law, and darin

Comment 49

[Doug Turner (:dougt)]

Checking in nsNativeAppSupportWin.cpp;
/cvsroot/mozilla/xpfe/bootstrap/nsNativeAppSupportWin.cpp,v  <-- 
nsNativeAppSupportWin.cpp
new revision: 1.91; previous revision: 1.90
done

Comment 50

[Susie Wyshak]

WORKS FOR ME!

I tested that while the "1" bug still occurs on earlier trunk builds, with the
5/2 build I can get into Yahoo Mail fine whether I click their mail notification
while logged into mail already or not, and whether the browser is already
launched or not. 

Thanks Doug!!!

Comment 51

[/\/\arcio Galli]

Worksforme - Very nice!!! ;) Thanks!

Comment 52

[Adam Egger]

Still not working for me with 
Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.4b) Gecko/20030502 
If I press the Homepage-Button on my keyboard, Mozilla starts with "1" as the URL. 

Comment 53

[sairuh (rarely reading bugmail)]

rs vrfy per susie and marcio. (i don't have yahoo messenger.) however, pls do
reopen if this is still a problem with recent builds.