28069 - Links in app sidebars don't always go to correct page

Status: VERIFIED FIXED

(SeaMonkey :: Sidebar, defect, P3)

Description

[scalkins]

In todays commercial release builds, I noticed with some apps, on some platforms 
links work in sidebar (Win & Mac Composer sidebar, and Aim sidebar on Mac), 
while on other platforms the links won't work in the sidebar for some apps (Win 
Aim, Linux w/Aim or Composer sidebars to name a few). When I say the Links don't 
work, I mean that they don't go where they should, i.e. clicking on Link "Mother 
sues over dead boxer" always seems to go to the "My Netscape" homepage instead. 

Win: 2000-02-16-09 M14
Linux: 2000-02-16-08 M14
Mac: 2000-02-16-08 M14
 
Steps to repro:
1)On Win 32, launch seamonkey and open Mail via Tasks-->Mail
2)In the Mail sidebar, click on the My News panel. Click on any news items under 
Top Stories.
3)Now launch Composer via Tasks-->Composer. In the Composer sidebar, click on 
the same link under My News panel.

Actual results: In Step 2- You are taken to the My Netscape home page. 
In Step 3- You are taken to the web page which goes into the story itself.

Expected results: Step 2 and 3: You are taken to the web page which goes into 
the story itself.

Comment 1

[scalkins]

Imporatnat note, I just found that in most cases if Navigator window is already 
open, it goes to My Netscape page. If Navigator was closed, and you click on a 
link in the sidebar, it opens a new Navigator window to the correct page. So the 
issue seems to be related to whether or not an existing Navigatopr window is 
open or not. If it is open, you see sporadic behavior from different apps when a 
link is clicked in it's sidebar.

Comment 2

[Scott MacGregor]

I've been looking into this bug and it is very strange. I've watched us
correctly attempt to load the url in the correct browser window (i.e. with the
correct netscape news url that I clicked on). But while loading that web page,
it has some JS that gets executed.

That JS is apparently replacing the url with http://my.netscape.com. So we abort
the correct url load and replace it with this new one.
Here's a small stack trace showing us trying to load my.netscape.com instead of
the original url requested. LocationImpl::Replace is being given this url from JS.

nsWebShell::DoLoadURL(nsIURI * 0x042e6590, const char * 0x00390030,
nsIInputStream * 0x00000000, unsigned int 0x00000000, const unsigned int
0x00000000, const unsigned short * 0x042e67f0, const char * 0x00000000, int
0x00000001) line 1687
nsWebShell::LoadURI(nsWebShell * const 0x040e64d0, nsIURI * 0x042e6590, const
char * 0x00390030, nsIInputStream * 0x00000000, int 0x00000000, unsigned int
0x00000000, const unsigned int 0x00000000, nsISupports * 0x00000000, const
unsigned short * 0x042e67f0, const char * 0x00000000) line 1969 + 44 bytes
nsWebShell::LoadURL(nsWebShell * const 0x040e64d0, const unsigned short *
0x0012e7fc, const char * 0x00390030, nsIInputStream * 0x00000000, int
0x00000000, unsigned int 0x00000000, const unsigned int 0x00000000, nsISupports
* 0x00000000, const unsigned short * 0x042e67f0, const char * 0x00000000) line
2190 + 53 bytes
nsWebShell::LoadURL(nsWebShell * const 0x040e64d0, const unsigned short *
0x0012e7fc, nsIInputStream * 0x00000000, int 0x00000000, unsigned int
0x00000000, const unsigned int 0x00000000, nsISupports * 0x00000000, const
unsigned short * 0x042e67f0) line 1437
LocationImpl::SetHrefWithBase(const nsString & {""}, nsIURI * 0x045780c0, int
0x00000000) line 395 + 113 bytes
LocationImpl::Replace(LocationImpl * const 0x042d8948, JSContext * 0x040d9d40,
long * 0x03593038, unsigned int 0x00000001) line 673 + 27 bytes
NSLocationReplace(JSContext * 0x040d9d40, JSObject * 0x027da0f0, unsigned int
0x00000001, long * 0x03593038, long * 0x0012ea50) line 492 + 35 bytes
js_Invoke(JSContext * 0x040d9d40, unsigned int 0x00000001, unsigned int
0x00000000) line 665 + 26 bytes
js_Interpret(JSContext * 0x040d9d40, long * 0x0012f3a8) line 2292 + 15 bytes
js_Execute(JSContext * 0x040d9d40, JSObject * 0x027d8e68, JSScript * 0x0431c8b0,
JSFunction * 0x00000000, JSStackFrame * 0x00000000, unsigned int 0x00000000,
long * 0x0012f3a8) line 836 + 13 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x040d9d40, JSObject * 0x027d8e68,
JSPrincipals * 0x04319044, const unsigned short * 0x03618028, unsigned int
0x00000131, const char * 0x0431cb90, unsigned int 0x00000005, long * 0x0012f3a8)
line 2740 + 27 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x040de9c0, const nsString & {"
<!--
s=location.search.substring(1,location.search.length)
newloc=s.substring(s.indexOf("/")+1);
if (navigator.appVersion.sub"}, void * 0x027d8e68, nsIPrincipal * 0x04319040,
const char * 0x0431cb90, unsigned int 0x00000005, const char * 0x00339468,
nsString & {""}, int * 0x0012f408) line 292 + 53 bytes
HTMLContentSink::EvaluateScript(nsString & {"
<!--
s=location.search.substring(1,location.search.length)
newloc=s.substring(s.indexOf("/")+1);
if (navigator.appVersion.sub"}, int 0x00000005, const char * 0x00339468) line 4079
HTMLContentSink::ProcessSCRIPTTag(const nsIParserNode & {...}) line 4271
HTMLContentSink::AddLeaf(HTMLContentSink * const 0x0457e3d0, const nsIParserNode
& {...}) line 2941 + 12 bytes
CNavDTD::AddLeaf(const nsIParserNode * 0x04318eb0) line 3217 + 22 bytes
CNavDTD::HandleScriptToken(const nsIParserNode * 0x04318eb0) line 1842 + 12 bytes
CNavDTD::OpenContainer(const nsIParserNode * 0x04318eb0, nsHTMLTag
eHTMLTag_script, int 0x00000001, nsEntryStack * 0x00000000) line 2895 + 12 bytes
CNavDTD::HandleDefaultStartToken(CToken * 0x02d1fc10, nsHTMLTag eHTMLTag_script,
nsIParserNode * 0x04318eb0) line 1075 + 20 bytes
CNavDTD::HandleStartToken(CToken * 0x02d1fc10) line 1389 + 22 bytes
CNavDTD::HandleToken(CNavDTD * const 0x04196710, CToken * 0x02d16960, nsIParser
* 0x0457e5b0) line 765 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x04196710, nsIParser * 0x0457e5b0,
nsITokenizer * 0x04309040, nsITokenObserver * 0x00000000, nsIContentSink *
0x0457e3d0) line 504 + 20 bytes
nsParser::BuildModel() line 1085 + 34 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 0x00000000) line 1000 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x0457e5b4, nsIChannel * 0x045797a0,
nsISupports * 0x00000000, nsIInputStream * 0x04579ce8, unsigned int 0x00000000,
unsigned int 0x000001fc) line 1378 + 19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x04579af0,
nsIChannel * 0x045797a0, nsISupports * 0x00000000, nsIInputStream * 0x04579ce8,
unsigned int 0x00000000, unsigned int 0x000001fc) line 262 + 46 bytes
nsHTTPResponseListener::OnDataAvailable(nsHTTPResponseListener * const
0x045782e0, nsIChannel * 0x0457aed4, nsISupports * 0x045797a0, nsIInputStream *
0x04579ce8, unsigned int 0x00000000, unsigned int 0x000001fc) line 194 + 58 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x0457a2c0)
line 370

Comment 3

[Scott MacGregor]

More analysis:

LocationImpl::SetHrefWithBase(const nsString& aHref,
                              nsIURI* aBase,
                              PRBool aReplace)
is getting called with aHref = "" and aBase == the correct url we are trying to
load.

This method ends up calling NewURI for an emtpy anchor using the base uri. The
uri we get back is my.netscape.com.

So we then turn around and load my.netscape.com into the webshell, aborting the
previous load for the real url.

Comment 4

[Scott MacGregor]

The JS in the netcenter document that is triggering this strange behavior looks
like:

<!--
s=location.search.substring(1,location.search.length)
newloc=s.substring(s.indexOf("/")+1);
if (navigator.appVersion.sub"}

evaluating this script triggers LocationImpl::Replace which in turn leads to our
problem.

Comment 5

[leger]

Putting on the PDT+ radar for beta1.

Comment 6

[Steve Lamm]

I have not had a chance to look closely at this yet, but it sounds like for 
beta we should just have netcenter change their content.

Comment 7

[don]

I agree.  John, can you find the appropriate Netcenter person and pass this bug
along to them?

Comment 8

[Scott MacGregor]

I don't understand why this bug would go to netcenter? I spent some time looking
at this the other day (I think I put some comments in this bug). The problem
doesn't exist in builds dated 2/15 for me. The problem does exist in 2/16 and later.

I'm sure the content on netcenter isn't changing depending on which build I'm
using =). Sounds like the client is doing something different between those two
dates.

Comment 9

[Paul MacQuiddy]

I'm cc:ing rginda on this, he made some js changes and some sidebar changes that 
may have affected this (the night before this bug was found), so I am 
suspicious. I agree, this is not a content issue either.

Comment 10

[Paul MacQuiddy]

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

Comment 11

[Michael La Guardia]

OK.  If this is not a netcenter issue, then the bug definitely shouldn't be
assigned to John.  Reassigning to Don so he can sort it out.

Comment 12

[Robert Ginda]

I doubt my changes could have introduced this, but I'll check it out.

Comment 13

[don]

Steve, find out what's going on here.

Comment 14

[Steve Lamm]

I am looking at this now.

Comment 15

[Steve Lamm]

This looks like a dup of bug 9472.

I made a test page,
http://dunk.mcom.com/sidebar/test-panel.html
That has a link that loads,
http://dunk.mcom.com/sidebar/redirect.html?cp=myre/http://my.netscape.com/news/Sports/02_22_2000.rossz1240-story-bcsportssummary.html

If you want to add the test panel to your sidebar, go to:
http://dunk.mcom.com/sidebar/add-panel.html

To reproduce the problem,
Add the test panel (url above).
Click on the test panel's link in the browser's sidebar.

When the new page loads and executes its JavaScript, window.location holds the
value for the previous page, not the current one.

Comment 16

[Andreas Otte]

Attachment: Since I have no access to the test (Netscape internal site) could someone test this patch against it?

Comment 17

[Steve Lamm]

Attachment: JavaScript to add a panel (test-panel.html) to the sidebar

Comment 18

[Steve Lamm]

Attachment: Test panel for sidebar with link to a page with a redirect

Comment 19

[Steve Lamm]

Attachment: A page that does netcenter style redirects.

Comment 20

[Steve Lamm]

The patch added by Andreas did not fix my problem. I have added the test pages
that I am using. In the test pages, any references to "dunk.mcom.com" need to be
changed to your local server.

Comment 21

[shrirang khanzode]

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

Comment 22

[rpotts (gone)]

Clicking on the attachment (5619) link does exactly the same thing in both
Navigator and mozilla...

What's the problem?

Comment 23

[Steve Lamm]

The bug still happens. Here is another way to reproduce it,

1. Add "Reuters News" to your sidebar
2. Open that panel and click on one of the headlines.

"my.netscape.com" gets loaded instead of the headline.

Comment 24

[Jim Roskind]

The blocker (listed in the status whiteboard) is now marked fixed.
Please update the status whiteboard with a landing date.
I'm adding the notation that this will become a PDT- on 3/10 (and removing the
outdated 9472 comment) on the status whiteboard.
Thanks,
Jim

Comment 25

[Paul MacQuiddy]

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

Comment 26

[Steve Lamm]

The blocker was not fixed.It was marked as a dup to 27048.Adding that as a blocker.

This bug, 28069, is really a duplicate of 27048 for engineering purposes, but
this bug serves as a seperate testcase (and a place to put more sidebar dups).

Comment 27

[steve]

It would seem that we're running a duplicate bug here,
my # of 29817 has been reported as a duplicate of here.

Update: Reinstalled build 2000012520 in order to get
the build number because it works, in that in my sidebar
the check webmail in Netcenter Apps takes you direct to
the post page and not to the start page of My Netscape.
However this is a 3 week old release of M 13 the alpha
one.

Comment 28

[Andreas Otte]

Great, bug 27048 is another one of this bugs with special permissions ... I hate
these ... so what really is the problem?

Comment 29

[Paul MacQuiddy]

Andreas, I put a note asking if the bug can become unconfidentialized - (it has 
a bit of netcenter stuff in it) The title is "need http clients to implement 
nsIHTTPEventSink"

Comment 30

[Andreas Otte]

Okay, that's all I wanted to know. Thanks. It's the month's old nsIHTTPEventSink
problem. 

Comment 31

[Scott MacGregor]

slamm, I believe this bug was fixed by something Norris checked in on Thursday
(or Friday).

The links from the sidebar that used to give me this problem are all now working
fine. I think you can mark this as fixed.

Comment 32

[Steve Lamm]

Yep, this is fixed.

Comment 33

[Paul MacQuiddy]

verified

Comment 34

[steve]

Hi All

Does anyone know when or if the Necenter Apps will be added back
into the customize menu in My Sidebar?
In the official M 13 alpha (Build 2000012520) release it was 
there and seemed to work correctly, in M 14(build 2000022808) 
it was also there but by clicking on Check Mail got
you only to the My Netcenter start page and not to the login for post.

Using build 2000031008 at the moment and no sign of Netcenter Apps.

Comment 35

[Paul MacQuiddy]

this bug should not have been re-opened, marking resolved and verified

a new bug should be re-opened if you want access to netcenter apps

Comment 36

[Paul MacQuiddy]

verified again