with a build today (on Mac), I see the dialog for xslt.alexa.com not being found as I surf (many times). This really affects my ability to use the product since the dialog pops up right on top of the current front window (which might be mail). My sidebar is closed so why is my browser trying to contact alexa.com?

Hi Kathleen, this is unrelated to xslt, despite the host name, the page is referenced in xpfe/components/related/ressources/related-panel.js. Moving to component sidebar, reassigning to owner sidebar. Axel

nav triage team: Under no circumstances should the What's Related tab (or any other sidebar tab) make server requests when closed. In the What's Related case, this is a privacy issue. nsbeta3+, P1, recommend dogfood-, adding keyword regression reassigning to pchen per don. See other related bug 46736, might be a regression of that bug.

johng: You say this absoultely should not be allowed to happen... but don't explain why this is not dogfood. Please give a reason to mark this minus, as it sure seems painful to surf if this dialog popped up endlessly :-(. Marking dogfood-plus for now... but please remove if this is easy to avoid.

PDT agrees P1

I completely agree. This can't happen. Actually, there seem to be 2 issues here: 1. The sidebar tab should not be making queries when closed 2. No error in the sidebar should interupt normal browser usage (especially not poping up dialogue windows constantly). There is no reason to bother a user about something that they haven't actually initiated themselves. BTW, someone might want to change the platform to "all", since this is happening to me on Win2k on a PC and the only platform listed currently is Macintosh. Jake

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

My mac ns6 build from this morning isn't popping up a dialog, thank goodness. I will try nightly build.

platform -> all per previous comments. what a luck that this annoying dialog popped up, or we might have missed this privacy invasion.

This is bad, but let's deal with it in the RTM timeframe.

Even though this is a P1, I'm making this "RTM NEED INFO" because so far engineering can't reproduce the bug.

it is a legal requirement that the What's Related tab does *not* ping the server when it is closed or when the Sidebar is closed. QA - please verify.

Tried to reproduce this problem on all branch builds for today but am unable to do so.:(

ok..finally got this message( the one kathy has mentioned) to appear on windows (god knows how)...but I see it on windows build 2000092908.

Crap! OK ... Paul, have you been able to reproduce this?

I'm still waiting for a reproducible case

qawanted

nav triage team: Does this problem still occur (but with a different URL) after Matt checks in his fix in bugscape 2792? Reassigning to Matt. If the problem no longer exists, can close this bug. Changing subject from: constantly see dialog for xslt.alexa.com not found as I surf to: What's Related surfing when it is closed - privacy issue

ok, here's how developers can reproduce the problem I have seen: * go into related-panel.js and change the alexa url to be something like: xslt.alexafoobar.com [our goal is to simulate when the server is down; a bad url should be sufficient for that] * rebuild your jar files if you need to * open your browser window to a url * make sure that your sidebar is not completely hidden (collapsed or open is needed to reproduce). * as you go from site to site, page to page, surfing, you'll get dialogs telling you some strange url could not be found. cc johng: to me, this seems like a privacy thing but maybe this is actually desirable? (I hope not!) My parents certainly won't recognize the alexa url that appears in the dialog. Also, the dialog says to "try again" uh.... trying to load the url in the urlbar again (of course) will reproduce the same dialog. Sounds like a frustrating time for anyone who has the misfortune to be surfing when the server is down. Is there any way to suppress this dialog for this url?

Since we're including their sidebar by default, has anyone verified that Alexa's privacy policy is compatible with ours? Do we even have a privacy policy? I wouldn't be surprised if Alexa is gathering more user data than we at Netscape would find acceptable.

For the case somebody doesn't know: ALexa is owned by Amazon (so somebody said in another bug), and Amazon is known to sell even data about its very own customers.

Note that the commercial build is not shipping with Alexa but with the old What's Realted service hosted by Netscape (see bugscape 2792). We put it into the builds to see if we could make it work, but there were privacy and other issues (some mentioned above) that we could not quite resolve in time for rtm. We may (and hope to) bring back the Alexa hosted tab after rtm. The question is if this bug still exists after we back out the recent code and use the old What's Related we had in PR1 and PR2. Keeping this bug open since it is essential that we verify that this is not a problem.

johng (and any others)-- this bug is *NOT* about alexa or a particular host. This bug is that the user gets dialogs when the host (be it alexa or netscape or ?) is unreachable. These dialogs are not helpful but instead are confusing and would lead a user to wonder what their product (be it NS6, mozilla, or an embedded app) is doing behind their backs. I wouldn't trust/use the software (except I know the mesages refer to the sidebar). I would envision a safe fix to be something along the lines of not displaying the dialog if the url is exactly the url used by the sidebar. A better fix would be to not do any queries when the sidebar is collapsed or hidden but I'm guessing this is too difficult for this stage or we'd already have made that not happen. One last note, I see this bug when I'm in the Search tab or other tabs in the sidebar. I wasn't expecting to be doing related links when I wasn't in that tab.

brade, I disagree. The bug here are the queries, not the dialog. People *will* find out what you are doing (at least via tcpdump). If you hide the dialog (the source is open), you will only look more guilty.

BenB--sorry I wasn't clearer. I don't think we should be making the queries; that is the ideal. However, if that fix isn't acceptable to PDT, at least we should disable the bogus dialogs for that url (and release note that the queries are being made). As for hiding the dialog vs tcpdump, only advanced users will be doing tcpdump; average/novice users will see the dialog. The problem reported here came about because the sidebar was collapsed when the server happened to be down. tcpdump will show that the requests are being made whether or not the server is down (but the dialogs only appear when the server is down). I hope that makes my position a little clearer (with regards to NS6 branch and mozilla trunk).

Kathy- the bug you are talking about should be opened as a different bug - please do so. The issue that we need to take care of for privacy reasons is the issue described in the title "What's Related surfing when it is closed - privacy issue". This privacy issue is what triaging approved by saying "rtm need info" and we changed the title to make that clear. I agree Kathy that the problem you describe is real, but *please* deal with that in a separate bug because we (Nav triage team) decided to deal with that after rtm and we need to stay focused on the major issue in this bug (privacy concern). cc'ing claudius since he is knows something about this issue and might be able to help shrir QA this - this is an important issue to test. I think Matt is checking in the What's Related changes now (so you will see the old UI for What's Related) - as soon as that happens, we should test this.

This bug should no longer be rtm, since NS6 has gone back to the PR2 "What's Related" tab.

Do we still have the new panel in Mozilla? If so, please fix either bug 50763 or (frist part of) bug 53571 (I prefer the latter).

for the record, I again saw this dialog on a build yesterday on Linux...

Matt, is this fixed with your checkin to revert what's related?

John - This needs to get a FIX ASAP, we are running low on QA cycles and time. Question? - Why is this still marked as "New"? Shouldn't it be Assigned to Matt?

Reverting back to the old related panel this should be fixed.

Looks like reverting back actually still has this problem. Once you close that panel you still have what's related firing. This was the default setting in 4.7 but i'm working on it.

rtm-, removing the panel from the sidebar is the 6.x way to turn off what's related. As in 4.x, what's related does its thing all the time once it's turned on. If you don't like that, turn it off by removing it from the sidebar. Despite the fact that some people will complain about this, the feature is totally above-board and can easily be disabled.

Adding msanz, danielmc and mcarlson to cc: list. Linda - How does this affect L10N builds?

International shares exactly the same privacy issues. We do exactly as the US does with respect to What's Related as a tab vs What's Related being served from Netcenter. Just discovered that the What's Related tab is dead in the latest FR build. Will file bugscape bug.

This is tagged "relnote-user," and I was about to put it in the release notes. However, in the online Help I advise people to turn this tab off or remove it if they don't want the feature to be active. It seems to me that the online help covers this, then.

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

I still see this bug in NS6 commercial builds from last week. Since this bug isn't being fixed for NS6 RTM and other bugs are being marked as a duplicate of this here is how I'd summarize the current state of this bug: (from hoju@visi.com 2000-09-21 21:46 entry) Actually, there seem to be 2 issues here: 1. The sidebar tab should not be making queries when closed 2. No error in the sidebar should interupt normal browser usage (especially not poping up dialogue windows constantly). There is no reason to bother a user about something that they haven't actually initiated themselves.

Probably this has occurred to someone else already, but a dandy way of demonstrating this bug is to simply unplug your network connection and then browse a server running on localhost (proably browsing local files would work fine too). That's what I was doing when I filed a duplicate of this bug.

I did a few things with Moz (2000112020, WinNT) and Ethereal <http://ethereal.zing.org/> to determine precisely when What's Related is shuffling off data to Alexa. 1. If What's Related is unchecked in the Tabs list, Alexa doesn't hear where I'm going. 2. If Mozilla is started and the What's Related tab is never selected, Alexa doesn't hear where I'm going. 3. If the What's Related tab is selected, Alexa hears where I'm going (expected -- and correct -- behavior.) 4. If the What's Related tab is then deselected, Alexa contirnues to hear where I'm going (bad behavior, should be corrected.) If there's any other cases folks want me to check out let me know.

Someone should clean up the Status Whiteboard and Keywords to reflect post-6.0 status. Just to get this on the radar, I changed nsbeta3 to nsbeta1.

until what's related is completely spec'ed out for the next release, we will not implement this. todd shd be working on the what's related specification and server issues. descheduling from mozilla0.8.

spam : changing qa to sujay (New Sidebar QA)

Marking nsbeta1- to get off the radar. Need to figure out what to do after we figure out what's going on with What's Related.

This bug is specific to mozilla. Any help would be good.

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

Marking nsbeta1- bugs as future to get off the radar

Matt, is your comment of 3/13 that this doesn't affect Netscape builds supported by recent QA efforts? It directly contradicts your prior statement on 10/25/00 and seems improbable given Matt Behrens comment unless some other checkin has fixed this. Please enlighten us :-) converting nomination from dogfood to catfood since we already shipped like this once and removing the panel from the sidebar (as we suggest in our help) fixes this problem. Was the bug for the dialog problem ever filed? This bug is NOT about that problem.

nav triage: severity of the problem does not warrant a nsCatFood, suitable workaround exists to remove the panel from your list.

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

> suitable workaround exists to remove the panel from your list. The workaround is non-obvious. Most users won't even notice that something is wrong (yet their privacy is violated). Adding relnote, although I don't hink that is sufficient. If you don't fix this bug in the soon, I'd say 'remove the panel altogether'. (That's what I did in Beonex Communicator.)

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

Why is this bug not fixed yet. Privacy issues should have absolute top priority (even over crashers). All that needs to be fixed is Matt Behrens comment #4 from 2000-11-21 07:06: "4. If the What's Related tab is then deselected, Alexa continues to hear where I'm going (bad behavior, should be corrected.)" Just fix #4 and we're all out of here. Don't fix #4 and Mozilla is seriously violating EVERY users right to privacy (tab is ON by default!). The fact that this is nsbeta1- and nsCatFood- (minus!!!) is a disgrace to Netscape. The fact that this is TM: "Future" is a disgrace to Mozilla.

could there be other problems with other (hypothetical) sidebar tabs caused by this issue?

See also bug 91168, Search sidebar compiles result list (eating CPU time) even when panel is not visible.

what is happening is that xul sidebar panels after being open don't get closed when you collapse the window. Only when you hide the sidebar

Can we get rid of the "if"? The "isSandboxed" call will never be executed.

patch posted so that chrome urls don't say open. Need r and sr and some one to check this sucker in since i'm not going to be able to. Oh ya need a A= also.

Ok, I verified with tcpdump that attachment 46945 [details] [diff] [review] mostly fixes the problem. With the sidebar open and the What's Related tab on the sidebar (default setting) but with a different tab selected, I no longer see screenfuls of alexa.com traffic. However, I do see 1 request/response pair within a minute or so after I've either selected another tab or closed the sidebar. Occassionally, I see the pair several minutes after the WR panel has been deselected. Still not sure how that is happening. r=cls

matt's patch is OK, but we should just remove the if from around the setAttribute call further down instead. However, won't doing this increase startup time when you reopen the sidebar, because content has to be reloaded? Gerv

Does this *really* fix the following cases: * If the user slides the sidebar edge next to the window edge, the panel should make no requests even if it was left as the topmost panel. * If another panel is selected, the what's related panel should make no requests. ? Last time I checked, the What's related panel prefs were deceptive, too, because they had no effect. (BTW, did you notice that Alexa has been the defendant in a class action lawsuit recently... The complaint described their software as "trojan horse". I still don't see why mozilla.org wants a partner like that.)

Ick. Bad choice of words. How does reopening the sidebar "increase startup time"? :-) Yes, it looks like the content will be reloaded whenever the panel is reactivated. No, the proposed fix does not work in the 0-width sidebar case. I'm not sure if I'd agree that a 0-width sidebar == inactive sidebar. Outside of the 1 or 2 pair of stray packets after selecting another panel (possibly a timers issue?), tcpdump verifies that no requests are being made. This is after running tcpdump and using the sidebar for most of the weekend.

Considering that most of our panels are fetching data from a remote site anyways, how bad, realistically, is it to reload the panel from its src url whenver it is selected? Especially, when the trade off is to have it disabled whenever it's not selected? I'm still looking to get this into 0.9.4.

So why can't we do something like: var search = Components.classes["@mozilla.org/rdf/datasource;1?name=internetsearch"] .getService(Components.interfaces.nsIInternetSearchService); var autoOpenSearchPanel = pref.GetBoolPref("browser.search.opensidebarsearchpanel"); if (!sidebar_is_hidden() || autoOpenSearchPanel) { var searchInProgressFlag = search.FindInternetSearchResults(url); if (searchInProgressFlag) RevealSearchPanel(); } I'm sure there's a good reason we can't just not post the url to the internet search service if the sidebar is hidden and we don't want it to auto-open on us, and I'm just not seeing that reason.

Comment on attachment 46945 [details] [diff] [review] patch to sideOverlay.js Oigh. Well this seems harmless enough. sr=ben@netscape.com

Comment on attachment 46945 [details] [diff] [review] patch to sideOverlay.js a=asa for checkin to 0.9.4

Attachment 46945 [details] [diff] has been checked into the trunk and the 0.9.4 branch.

Replying to my own 2001-08-23 23:14 comment: The case with another panel has been selected appears to be fixed. When "What's Related?" is the previously used panel but the sidebar has been minimized, Mozilla sends requests to xstl.alexa.com, which is both a privacy and performance problem. Should I reopen this bug or file another one?

Removing ME.

Henri, define "minimized".

With "minimized" I mean the state the sidebar goes into when the grippy of the open sidebar is single-clicked (with no dragging).

As the author of this bug, I don't consider it fixed if my sidebar is trying to contact alexa.com while it is collapsed/minimized. Reopening bug based on Henri's comments.

Now to play the other side of the coin....I disagree with the entire minimized == inactive premise. When you minimize, iconize or shade an application window, it does not become inactive. I don't see why the sidebar should be any different. If I have a panel that actively streams data and I want to free up some screen space, I should be able to minimize it (via the grippy) and not lose the data. If I want to turn it off, then clicking another tab or disabling the sidebar (via F9) should be the way to do it. I think this entire conversation would be moot if there was a non-menuitem/hotkey way to disable the sidebar like there is to minimize it. (Wrt WR, we know that's a privacy issue by itself, minimized or not. So if you have it selected, then you know what you're in for. )

Cristopher: From a user point of view i strongly disagree with your view. If i hide (or otherwise) disable a sidebar applet i assume it is no longer active ("out of view") and certainly i would not expect it to send out information -- independendly if i previously selected it or not.

Reassigning to default owner & QA.

cls, if you disable the sidebar completely (View | Sidebar), would you expect the panel to continue to fetch? I certainly wouldn't. The average user doesn't notice the difference between collapsed and disabled (and it is arguable, if there should be any at all). Besides, rereading the inital description and the summary, the collapsed state is what this bug was all about, not?

The behaviour should orient itself according to what the user expects. If something is closed, minimized or another item is selected, he usually doesnt want stuff to be happening. Therefore: - When the sidebar tab is closed (i.e., another tab is selected), there should be no updating. - When the sidebar itself is minimized, collapsed, closed or whatever, there should be no updating.

BenB: Obviously, I did see fetching when the sidebar was disabled as a big problem as I pushed quite a bit to get Matt's fix in. However, I do not see an active sidebar (ignoring WR) as a problem. "Disabled" and "collapsed/hiding" are distinct states. By combining those states into a single state, you lose potential flexibility with the sidebar (think internet radio). There are two distinct states for a reason. Even in these "minimized" state, there is still the presence of the sidebar. That should be the first clue that it's not *disabled*. If the "average user" thinks that something is "disabled" merely because it's "hidden" or "minimized" or "collapsed", they are fooling themselves and I have no intent of harboring their misconceptions and I don't think the project should either. Does our browser stop loading a page when you minimize the window? Of course not, because you didn't *disable* the application. You merely hid it. If the "average user" can understand that simple idea, then they should be able to understand this sidebar issue. We should not "dumb down" a potentially useful feature because the "average user" has logistically incorrect expectations.

What about the fact that users will want to have the "what's related" sidebar available in the sidebar, but have another sidebar (e.g., bookmarks) open *most* of the time. Would the rarely used but *available* "what's related" sidebar still be sending signals? Thi seems to be something different than a minimized window - which therefore seems to need a new and different solution. Or am I misunderstanding something here?

As of Matt's patch (which has been checked in for 0.9.4 & the trunk), only the currently selected sidebar panel is active. And it is only active when the sidebar is enabled (regardless of the minimized/collapsed state). So for your example, only the bookmarks panel will be fetching new data.

The tab persistence featuer will address this. Taking for 0.9.5.

-> Matt fixed this.

Resolving.

marking VERIFIED per brade.

Seems like this bug has never been fixed correctly or it regressed. Filed a new, clean bug 133073.