58094 - multi related link clicks does not update related

Status: VERIFIED FIXED

(SeaMonkey :: Sidebar, defect, P1)

Description

[matt]

Click on related link
updates related links panel
click on related link again
updates to portals in related link (shouldn't)
click again
give same results.

Comment 1

[don]

Uh oh.  This is definitely a "need info".

Comment 2

[don]

This is scary.  P1.

Comment 3

[shrirang khanzode]

cc:johng

Comment 4

[Blake Ross]

Wait, so what's the problem?  That the related links don't update as you keep 
clicking links in the panel?

Comment 5

[Blake Ross]

OK, here's what's up...

Apparently, whenever you click on a what's related link, you're really going to 
http://info.netscape.com/fwd/rlstatic/(urlofwhateveryouclicked).  That's the 
data we get back from the content observer.  Thus, when we extract the top-
level domain, it's always info.netscape.com, which is why we always get those 
same set of portal related links.  I assume the `rl' in `rlstatic' stands for 
`related links'.  Is this some kind of marketing tracking scheme or something?  
It's a pretty big privacy issue, especially if Netscape can track every URL a 
user visits.  John, could you clarify?

And where is this URL specified, anyways? I couldn't seem to find it anywhere.

Reassigning to me while I investigate...

Comment 6

[Blake Ross]

Oh, I suppose that URL's specified on the server-side.  This is probably needs 
to be fixed on netcenter's end, if that's possible.  I suppose we could get the 
part of the data after the redirect URL, but if 
http://info.netscape.com/fwd/rlstatic/ is indeed for tracking then it really 
needs to be removed.

We need Netcenter or marketing clarification here before going any further...

Comment 7

[matt]

I have a fix for this.
So I check to see if the url is from info.netscape.com
and then strip that part of the url and use the original part.
Attached is the fix.  Please review.

Comment 8

[matt]

Attachment: patch for bug

Comment 9

[Alec Flett]

patch looks like it will work, but doesn't netcenter want the redirect for
tracking purposes? or is "newSite" not used to actually load the URL?

Comment 10

[matt]

newSite does not load the url.  It only goes off to netcenter to
get the related linkes.
Handler.URL loads the content space and that remains untouched.

Comment 11

[Bill Law]

r=law

Comment 12

[Blake Ross]

Wait...

I know this is an acceptable patch, but do we want to hardcode 
info.netscape.com like that?  And in Mozilla builds, where the URL could 
possibly change?

Comment 13

[Blake Ross]

Also, see my 10/26 comment:

"I suppose we could get the 
part of the data after the redirect URL, but if 
http://info.netscape.com/fwd/rlstatic/ is indeed for tracking then it really 
needs to be removed."

Could someone please clarify if this is indeed for tracking, and if so, what 
it's tracking?  It seems like this could be used to track where the user goes 
(e.g. what related links he clicks on), which, even if Netscape isn't 
collecting that data (and I assume they aren't), is still a major privacy 
concern.

Comment 14

[matt]

We can pull this out to navigator.properties if we want.
I'm not wanting to put this into the trunk since alexa's
related is so much better. 

Yes this is a tracking url.  There are privacy concerns but
we are already sending the url to the server anyways.  Aleka is doing
this also.  That is the pain you suffer for getting a service like what's 
related.   We do this on 4.x also.

Comment 15

[Blake Ross]

Oh, that's right -- this is branch-only.  I guess it's OK then...

Although I would disagree that this comes with using the service.  I don't see 
how it would be necessary to have every URL go through a redirect in order for 
the service to work.  And `it comes with using the service' probably isn't 
going to pacify privacy advocates.  But none of this is my concern, so...

I guess the patch can be checked in.  Thanks for taking the time to make it.

Comment 16

[don]

PDT folks, do you want to take this for the "limbo" release?

Comment 17

[selmer (gone)]

This bug is in candidate limbo.  We will reconsider this fix once we have a 
candidate in hand, but we can't take this fix before then.  Please check into 
the trunk ASAP.

Comment 18

[matt]

The trunk has the Alexa's what's related panel
which is much better so we won't check this into the trunk. And
to check it into the nscp branch we need to seperated
the what's related stuff from mozilla which will require much
more work.

Comment 19

[johng]

Except for the tab that is open by default, this tab gets far more traffic/
usage then any other tab.  It is therefore a highly visible problem - thanks for
including this if possible.

As for the trunk question, Matt is going to make a jar file so QA can verify it
- just to make extra extra extra sure that this very simple fix is safe.

Emailing Alexa to remind them to keep their tab alive for mozilla builds (which
other companies will use and will reduce risk if we include this or something
like it in the future.).

Comment 20

[matt]

I'm giving this to myself so i since when they approve it
i can find it fast to check in the patch.

Comment 21

[matt]

This works nicely on my 10/30 branch candidate build on windows. Related links 
are refreshed when I click on one of the
links from 'What's Related'. 

Shrirang 

Comment 22

[selmer (gone)]

rtm++, please checkin ASAP so we can build today.

Comment 23

[matt]

.

Comment 24

[shrirang khanzode]

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

Comment 25

[shrirang khanzode]

verified fixed on the branch build on windows (limbo 2, 20001101). Still see the 
blank tab problem on mac/linux(bug 58009). Was this fix meant only for windows? 

Comment 26

[shrirang khanzode]

ok, retried on mac and linux limbo2 builds(11/01) and this works often (with bug 
58009)
Adding keyword: vtrunk.

Comment 27

[shrirang khanzode]

I mean bug 58099 in my earlier comment.

Comment 28

[shrirang khanzode]

removing 'vtrunk' keywd. verified on trunk builds 1129( used workaround for bug 
57290).