Closed
Bug 218516
Opened 21 years ago
Closed 15 years ago
Don't List Links Opened As Background Tabs As Visited Until Viewed
Categories
(Toolkit :: Places, enhancement)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mozillabugzilla, Unassigned)
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6 Any link that is opened as a background tab is immeidately listed as visited. This "visited" status is sometimes at odds with the user's experience (i.e. they shut down the browser before all of the tabs have been viewed) Reproducible: Always Steps to Reproduce: 1. Go to a site such as Slashdot. 2. Open numerous articles / links as background tabs 3. Close some or all of the background tabs before viewing them Actual Results: All links that were opened as background tabs (even those not yet actively viewed by the user) are now listed as visited Expected Results: I believe that it would be helpful to include as a preference the following: If a link is opened in a background tab, don't consider said link as "visited" until the background tab has been viewed.
Comment 1•21 years ago
|
||
-> Browser - Tabbed Browser (needs backend changes before the tab handling).
Assignee: blake → jag
Component: General → Tabbed Browser
Product: Firebird → Browser
QA Contact: asa → pmac
Version: unspecified → Trunk
Comment 2•21 years ago
|
||
visited means that the client loaded the URL and this is true. I suggest wontfix
Reporter | ||
Comment 3•21 years ago
|
||
I would say that your definition of whether a URL has been visited should be reconsidered because tabs have been introduced. Has Mozilla visited the URL even though it was only loaded in a background tab? Yes. Has THE USER visited the URL even though it was only loaded in a background tab? Some would say "Not yet." My recommendation would be to have the default behavior stick with what's currently being done, but it would be very useful from a user perspective to be able to not mark links as visited until they've been actively viewed by the user. I agree with your implicit statement that the current behavior is not a bug. That's why I submitted it as a "Severity: Enhancement" :).
Comment 4•21 years ago
|
||
The same argument applies to windows. Has the user visited a site loaded in a new window just because the new window has been opened? No -- the user may not even have looked at it... (esp. if the window came up in the background, as is possible).
Reporter | ||
Comment 5•21 years ago
|
||
You have an excellent point in that a similar situation is attainable pre-tabs, so to speak. However, almost everyday I get home from work, load up twenty background tabs to read the day's Slashdot / Linux Today stories and begin to read over dinner. I would never do this with twenty "background" windows. If the browser gets shut down for whatever reason (and it does happen on occasion) before I've read all the stories, the fact that they are flagged as visited becomes useless to me, because it does not correlate with my actual experience of reading them or not! The ability to use tabs has changed my behavior as a user and I would believe that the tracking of what's been visited or not should evolve to match this. My main point in this is that adding this feature will allow the software to more accurately present the information (specifically, what has been visited and what hasn't) based on the ACTUAL USER EXPERIENCE, and not a technicality that the information has been retrieved by the browser. With more users loading numerous pages in the background to be queued for reading (thanks to the utility of tabs) the visitation tracking should evolve to match this new behavior.
Comment 6•21 years ago
|
||
Agreed, there. So the question is how visited checking can be rearchitected accordingly... right now it uses the global history, and I think we _do_ want to add pages to global history even if the user has not ever looked at that tab....
Reporter | ||
Comment 7•21 years ago
|
||
My suggestion, from a non-developer standpoint... Within the Options / Preferences area, have two radio buttons allowing the user to choose whether to consider a link visited based on a tab being opened or the tab being viewed. Have these radio buttons directly beneath the option to load tab in the background. Since the default behavior of Mozilla is to open tabs in the foreground, have said radio buttons grayed out by default (after all, if you open a tab in the foreground you view it at the same time as the browser grabs it.) If the user decides to be like me and open tabs in the background, then the radio buttons become changeable and the user can choose to either have visitation be considered on-load or on-view. I leave it to the developers (because it's beyond my skill!) to decide whether the default should be on-load or on-view, and how to implement all of this in the code.
I think the additional utility of doing this is not worth the amount of work that would be required. In particular, I think I prefer the current way to what's proposed -- it (assuming we update links correctly when opened) allows the user to see which links have been opened in other tabs and which haven't.
Comment 9•21 years ago
|
||
Comment 6 was about how to implement this in the code if we decide to do it. Basically, a serious rewrite of one or both of the following would be needed: 1) How we decide whether a link is visited 2) How history works The former is likely to have a noticeable performance impact, actually...
Reporter | ||
Comment 10•21 years ago
|
||
Since I'm not a developer, I would not fault you for delaying / deep-sixing this for technical reasons. I'd love to see the feature added, but since I'm not the one with the skill to implement it, I promise not to whine if it is delayed / deep-sixed.
Assignee | ||
Updated•16 years ago
|
Product: Core → SeaMonkey
Updated•16 years ago
|
Assignee: jag → nobody
QA Contact: pmac → tabbed-browser
Comment 11•15 years ago
|
||
WONTFIX based on comment 8 and comment 9. Moving to Toolkit::Places as recommended by KaiRo
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Component: Tabbed Browser → Places
Product: SeaMonkey → Toolkit
QA Contact: tabbed-browser → places
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•