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

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.

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

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

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

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

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

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!

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

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

Shouldn't this be assigned to a networking engineer?

-->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?

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)

Yay - wfm also with 12-3 trunk.

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?

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)

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

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

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?

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

-->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?

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

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

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

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).

Changed subject from: Cannot login to Yahoo Mail using Yahoo Messenger to URLs from 3rd party apps-->Mozilla pass URL as "1"

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?

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.

We would not hold the 1.3beta release for this.

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.

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

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?

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

to darin.

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.

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.

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.

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

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

I see it on Windows NT 4.0

And WinXP - SP1 for me with Moz 1.3.

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

I'm nominating this to block 1.4.

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

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.

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

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

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 on attachment 122224 [details] [diff] [review] closer to fine. v.1 a=sspitzer thanks dougt, law, and darin

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

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!!!

Worksforme - Very nice!!! ;) Thanks!

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.

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.