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

VERIFIED FIXED in mozilla1.4beta

Status

VERIFIED FIXED
16 years ago
6 years ago

People

(Reporter: castaban, Assigned: dougt)

Tracking

({topembed-})

Trunk
mozilla1.4beta
x86
Windows 2000
topembed-
Bug Flags:
blocking1.3b -
blocking1.4 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [makes mozilla poor "default browser" for YIM users], URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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

16 years ago
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

16 years ago
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

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

Updated

16 years ago
URL: N/A
Status: UNCONFIRMED → NEW
Ever confirmed: true
Could you try a nightly build?  If it doesn't exist in a nightly build, please
resolve this bug as WORKSFORME.

Comment 5

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

Comment 6

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

Comment 7

16 years ago
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

16 years ago
-> networking for analysis. thanks to dwx for finding the dupe.
Component: Browser-General → Networking

Comment 9

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

Comment 10

16 years ago
Shouldn't this be assigned to a networking engineer?

Comment 11

16 years ago
-->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?

Assignee: asa → dougt
(Assignee)

Comment 12

16 years ago
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)
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 13

16 years ago
Yay - wfm also with 12-3 trunk.
Status: RESOLVED → VERIFIED

Comment 14

16 years ago
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?
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---

Comment 15

16 years ago
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

16 years ago
Good news - Spoke to Yahoo. It's a Yahoo issue that they will fix.
Assignee: dougt → susiew
Status: REOPENED → NEW
Component: Networking → US General
Product: Browser → Tech Evangelism
QA Contact: asa → zach
Version: Trunk → unspecified

Updated

16 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 17

16 years ago
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
(Reporter)

Comment 18

16 years ago
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

16 years ago
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

16 years ago
-->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?
Assignee: susiew → dougt
Status: ASSIGNED → NEW
Component: US General → Networking
Product: Tech Evangelism → Browser
QA Contact: zach → benc
Target Milestone: --- → Future
Version: unspecified → 1.0 Branch
(Reporter)

Comment 21

16 years ago
I too have seen this with a lot of other applications, which again suggests it
has nothing to do with Yahoo Messenger
(Assignee)

Comment 22

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

Comment 23

16 years ago
Emailed Doug with some more info. Allen it would be interesting to know which
apps and builds you saw this with.
(Reporter)

Comment 24

16 years ago
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

16 years ago
Changed subject from: Cannot login to Yahoo Mail using Yahoo Messenger

to
URLs from 3rd party apps-->Mozilla pass URL as "1"
Summary: Cannot login to Yahoo Mail using Yahoo Messenger → URLs from 3rd party apps-->Mozilla passing URL as "1"
Whiteboard: [talk to susiew]

Updated

16 years ago
Keywords: nsbeta1, topembed

Updated

16 years ago
Blocks: 178882

Comment 26

16 years ago
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

16 years ago
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.
Flags: blocking1.3b?
Target Milestone: Future → ---
Version: 1.0 Branch → Trunk
We would not hold the 1.3beta release for this.
Flags: blocking1.3b? → blocking1.3b-

Comment 29

16 years ago
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.
Keywords: topembed → topembed-
(Assignee)

Comment 30

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

Comment 31

16 years ago
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

16 years ago
behavior here is consistent with bug 95977, but I have no idea what the
mechanism here.
(Assignee)

Comment 33

16 years ago
to darin.
Assignee: dougt → darin

Updated

16 years ago
Target Milestone: --- → Future

Comment 34

16 years ago
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

16 years ago
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

16 years ago
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

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

Comment 38

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

Comment 39

16 years ago
I see it on Windows NT 4.0

Comment 40

16 years ago
And WinXP - SP1 for me with Moz 1.3.
(Assignee)

Comment 41

16 years ago
There is a bug in the DDE handling.  I tracked it down to
HandleDDENotification() and ParseDDEArg() in nsNativeAppSupport.  
Assignee: darin → law
Component: Networking → XP Apps: Cmd-line Features
QA Contact: benc → sairuh

Comment 42

16 years ago
I'm nominating this to block 1.4. 
Flags: blocking1.4?
(Assignee)

Comment 43

16 years ago
spoke to bill yesterday, he is not working on this.  over to samir.
Assignee: law → sgehani
(Assignee)

Comment 44

16 years ago
Created attachment 121836 [details] [diff] [review]
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.
giving to doug.

or doug, was it your idea to hand off the patch?
Assignee: sgehani → dougt
Flags: blocking1.4? → blocking1.4+
Whiteboard: [talk to susiew] → [makes mozilla poor "default browser" for YIM users]
Target Milestone: Future → mozilla1.4beta
(Assignee)

Comment 46

16 years ago
Created attachment 122224 [details] [diff] [review]
closer to fine. v.1

Took bill law's suggestion and created a new ParseDDEArgs that takes a (const
char*) as the first param.
Attachment #121836 - Attachment is obsolete: true

Updated

16 years ago
Attachment #122224 - Flags: review+

Comment 47

16 years ago
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.
Attachment #122224 - Flags: superreview+
Comment on attachment 122224 [details] [diff] [review]
closer to fine. v.1

a=sspitzer

thanks dougt, law, and darin
Attachment #122224 - Flags: approval1.4b+
(Assignee)

Comment 49

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

Status: NEW → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 50

16 years ago
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

16 years ago
Worksforme - Very nice!!! ;) Thanks!

Comment 52

16 years ago
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.
Status: RESOLVED → VERIFIED

Updated

10 years ago
Component: Cmd-line Features → Cmd-line Features
Product: Core → Core Graveyard
QA Contact: bugzilla → cmd-line
You need to log in before you can comment on or make changes to this bug.