Closed Bug 267313 Opened 20 years ago Closed 20 years ago

second external link opened into Mozilla opens the home/start page

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jsmith, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files)

DDE settings
35.61 KB, image/png
Details
Possible patch
1.22 KB, patch
benjamin
: review+
neil
: superreview+
asa
: approval1.8a5+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041101
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041101

When I double click on a URL on another program which then calls up my default
browser (i.i. Mozilla) the first time it gors to the correct URL. The second time
it opens up with the welcome to Mozilla page. This occurs when I use MS Outlook
and the BBC ticker program. I feel sure it will also do this for any program that
calls the default browser. I had not noticed this till the last few overnite
versions.

Reproducible: Always
Steps to Reproduce:
1.open MS Outlook to a message with a URL shown.
2.Mozilla opens up the correct URL.
3.open a different MS Outlook message and click on the URL.
4.Mozilla open up with the Welcome to Mozilla page


Actual Results:  
on second URL and later Mozilla goes to the Welcome to Mozilla page.

Expected Results:  
go to the proper URL EVERY time a URL is clicked from any program.

When I am in a URL and click on another URL Mozilla acts normal. This seems to be
a problem ONLY when Mozilla is called from another program.

The Welcome to Mozilla URL is: http://www.mozilla.org/start/  AND it comes up in
it's own window.

P.S. If I have this under the wrong catagory PLEASE feel free to edit that.
*** Bug 267310 has been marked as a duplicate of this bug. ***
*** Bug 267312 has been marked as a duplicate of this bug. ***
*** Bug 267319 has been marked as a duplicate of this bug. ***
I've noticed this as well - it's the home page though, not necessarily the
default mozilla start page.  The correct behavior with my prefs is to replace
the current tab, but the actual behavior is a new window coming up, at the home
page.

timeless suggests blaming danm.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can take a look, but I have a good alibi for the "blame" thing: I haven't
touched the trunk in months.

Point of order: this bug and its three duplicates were all filed by the same
guy, at 6:48, 6:50, 6:52 and 7:13. Methinks we can discard the extra urgency
normally allotted bugs with lots of duplicates.
Summary: Mozilla called from another program breaks on 2nd try → second external link opened into Mozilla opens the home/start page
similiar bug is Bug 266563
Depends on: 266563
(In reply to comment #5)
> I can take a look, but I have a good alibi for the "blame" thing: I haven't
> touched the trunk in months.
> 
> Point of order: this bug and its three duplicates were all filed by the same
> guy, at 6:48, 6:50, 6:52 and 7:13. Methinks we can discard the extra urgency
> normally allotted bugs with lots of duplicates.

I am Jerry Smith and I sent this bug in only once ( I hope )
Blocks: 267110
as of build 2004110305 the problem is still there.
Flags: blocking1.8a5?
Per discussion with Asa, marking blocking1.8a5+
Flags: blocking1.8a5? → blocking1.8a5+
Tracy, can you help us get a regression window for this?
*** Bug 270166 has been marked as a duplicate of this bug. ***
With respect to the urgency of the problem, although a PITA, it's certaintly not
critical.  However, I get enough e-mail with URL's in it and I also run virtual
desktops with many instances of Mozilla running which makes the bug painful (to me).

I'll keep myself on the bug CC list and await a 1.8.x fix while I install 1.7

Thank you folks for the hard work.
From testing and reading this bug and bug 266563, I believe they are dupes.  The
other bug doesn't have concise steps to reproduce.  I've asked for clarification
there.  Based on comments there, external links opening properly regressed
between 10/25 and 10/26
adding a few people who checked in during the regression window to see if they
can help here. 
I am not understanding how I am supposed to link these bug reports but as far as
I can see this bug is the same as 266563.  Just a better description of the bug
found.  If Someone can link them for me I would appreciate that. 
This regressed between 5:30am PST on 10/25 and 5:30am PST on 10/26.  I'm in the
process of building 5:30pm 10/25.  Hopefully over the next few hours I'll have
it narrowed down to one checkin.
(In reply to comment #16)
> This regressed between 5:30am PST on 10/25 and 5:30am PST on 10/26.  I'm in the
> process of building 5:30pm 10/25.  Hopefully over the next few hours I'll have
> it narrowed down to one checkin.

This regressed between 8:45am and 12:00pm.
Correction, my times were off by an hour (daylight saving).  I traced through
the DDE code, and it looks like advanceToEndOfQuotedArg isn't working right. 
ParseDDEArg receives what looks like good data, but it gets corrupted.

Handling dde request: ["http://bash.org/?364339",,-1,0,,,,]...
Handling dde XTYP_REQUEST request: [mozilla -url "]...
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041116] (nightly) (W98SE)

I tried to reproduce with two HTTP shortcuts, and failed.
(I would need more detailed steps !?)
Hi Serge,

I provided a list of steps in my dup bug 267313

Do those steps enable you to reproduce the problem?
Correction:  bug 270166 rather
Attached image DDE settings — 
(In reply to comment #21)
> Correction:  bug 270166 rather
These are the DDE settings I use - note I'm on Windows XP, so Win98 might be
different.
Note that calling code did change:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpfe/bootstrap&command=DIFF_FRAMESET&file=nsNativeAppSupportWin.cpp&rev1=1.102&rev2=1.103&root=/cvsroot

bernd helped step through the DDE code... it looks like 
http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsNativeAppSupportWin.cpp#1680
should really be using "+=" instead of "=".  FindChar returned 1, which was the
distance from end of the URL to the next comma, instead of 24, the offset of
that comma from the start of the string.  I'll have to look into this in more
detail later.
There was a bug in the calling code that was changed as noted. It allocated a
buffer 1 character too short. Now, if there was " in the end of the string, it
would have been stripped. In this case FindChar would have been unable to find
it and the code at
http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsNativeAppSupportWin.cpp#1680

seemed to work. What FindChar returns isn't exactly what I would have expected
(that's probably the cause of this bug) but what CTho said (offset relative to
the offset given to FindChar, see
http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsStringSupport.h#92).
Hence the suggestion of changing = to += is correct.
no, nsStringSupport.h's implementation of FindChar is wrong and inconsistent
with the other implementation at
http://lxr.mozilla.org/seamonkey/source/xpcom/string/src/nsTSubstring.cpp#657

hence, I suspect changing nsStringSupport by replacing:
 98               return p - data;
with:
                  return p - get();
would fix the bug. I can't test that currently.

alternatively data could be initialized with get() and p with get() + offset.
Ok, much better. I wrongly assumed FindChar is an old trustworthy function.
Attached patch Possible patch — — Splinter Review 
How about fixing it this way? If it's good, could someone drive it in for me?
Attachment #166701 - Flags: superreview?(jag)
Attachment #166701 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 166701 [details] [diff] [review]
Possible patch

I agree with ere that FindChar should return the offset from the beginning of
the string like
http://lxr.mozilla.org/seamonkey/source/xpcom/string/src/nsTSubstring.cpp#657
Attachment #166701 - Flags: review?(darin)
Attachment #166701 - Flags: superreview?(jag)
Attachment #166701 - Flags: superreview+
Attachment #166701 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #166701 - Flags: review?(darin)
Attachment #166701 - Flags: review+
Attachment #166701 - Flags: approval-aviary?
Comment on attachment 166701 [details] [diff] [review]
Possible patch

a=asa for 1.8a5 landing.
Attachment #166701 - Flags: approval1.8a5? → approval1.8a5+
bsmedberg, afaict this is not an issue on the aviary branch... 
http://lxr.mozilla.org/aviarybranch/find?string=stringsu
timeless landed this on the trunk, marking FIXED.
for real, now.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment on attachment 166701 [details] [diff] [review]
Possible patch

Oops, I had meant to set the approval1.8a5? instead of approval-aviary, force
of habit.
Attachment #166701 - Flags: approval-aviary?
*** Bug 266563 has been marked as a duplicate of this bug. ***
*** Bug 271165 has been marked as a duplicate of this bug. ***
Please explain how to apply the patch and why it is not included in the normal
nightly updates.

Alan: this will be included in the normal nightly builds. The checkin happened
in the afternoon, so it won't appear until the next nightly build (which will be
in about 8 hours from now).
I have verified this works in my environment:  WIN2K, Outlook 2000, etc

Thank you folks.
as of build 2004112206 it works as it should. thanks, Jerry
Verified FIXED using build 2004-11-22-06, yay (WinXP).
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
*** Bug 270886 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: