Closed Bug 141615 Opened 23 years ago Closed 5 years ago

Prioritize first tab in loading bookmark groups

Categories

(SeaMonkey :: Bookmarks & History, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bamm, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [2012 Fall Equinox])

A bookmark group loads all tabs at the same time, so the user cannot read any of them until all have loaded. It would be good if the first tab had priority in download so it could be read while the others are still loading. Great for users with slow connections.
Summary: [RFE] Prioritize first tab of bookmark groups in loading. → [RFE] Prioritize first tab in loading bookmark groups.
When all pages are trying to load at the same time, it nearly defeats the benefit of opening groups in tabs. This change would make a lot more sense to me. Otherwise opening a group of bookmarks slows down the browsing experience, rather than speeding up, as was envisioned. I imagine that the first page in the group should be loaded first, then the other pages should either load together, or load in the order of the bookmarks in the group. Which method do you think is better? I don't care much, except that the first bookmark should load before the others.
I think this bug may be dupe of a more general problem: current tab should have dl priority over background tabs -> networking
Status: UNCONFIRMED → NEW
Component: Bookmarks → Networking
Ever confirmed: true
-> networking, part deux
Assignee: ben → new-network-bugs
QA Contact: claudius → benc
What is the bug of the more general problem? I agree that when that is solved then this will be solved too. That maybe that should be marked a dependency of this one? Otherwise, feel free to dupe me.
-> browser-general Whatever code decides to fire all these requests is the place a fix should occur. I don't know anything about tab loading, so I'm sending it out.
Assignee: new-network-bugs → Matti
Component: Networking → Browser-General
QA Contact: benc → imajes-qa
-> Bookmarks
Assignee: Matti → ben
Component: Browser-General → Bookmarks
QA Contact: imajes-qa → claudius
Depends on: 142255
Hmmm, quite interesting request. While not quite the same as priority, content ratings (bug 91837) are one way to measure importance of a tab, and might be helpful here. The suggested schemes also remind me that a queue of bookmarked content could be work as a solution here (bug 91832). Prioritized loading could occur for bookmarks 1 to n, and for bookmark groups larger than n, these could wait in a queue to load until some of the initial tabs have closed.
*** Bug 143216 has been marked as a duplicate of this bug. ***
Instead of prioritising (yes, i'm australian :-) can we call it tab queuing. For example if I had a ten bookmarks in a group to load, then moz will check preferences to see how many bookmarked tabs it can load concurrently in one window. When one tab has finished loading it will go on to load the next bookmark etc etc etc until its all loaded. It'd be a major benefit for those still stuck on the 56.6k method (like myself)
See also bug 257453, Deferred Loading for "Open in Tabs".
Product: Browser → Seamonkey
With the patch for bug 142255 (that just landed), it is possible to dynamically adjust the priorities of any pending HTTP requests. I suggest that we give a priority boost to any requests in the active tab, or alternatively reduce the priority of any requests in a non-visible tab. We can access pending requests from the nsILoadGroup on each nsIDocumentLoader (which is implemented by the docshell). We may have to jump through some hoops to access the HTTP channel corresponding to an imgIRequest though.
(In reply to comment #11) > With the patch for bug 142255 (that just landed), it is possible to dynamically > adjust the priorities of any pending HTTP requests. I suggest that we give a > priority boost to any requests in the active tab, or alternatively reduce the > priority of any requests in a non-visible tab. We can access pending requests > from the nsILoadGroup on each nsIDocumentLoader (which is implemented by the > docshell). We may have to jump through some hoops to access the HTTP channel > corresponding to an imgIRequest though. That's a GREAT idea. For that matter, I would have just assumed it already did that. Please make it happen, thanks.
Should the focus or minimization of a window, affect the prioritization of the focused or unfocused tabs? That is, perhaps we ought to lower the priority of the focused tab in a minimized window to that of an unfocused tab or even lower the priority of all the minimized tabs to a certain level. Kapish?
Assignee: bugs → nobody
QA Contact: claudius → bookmarks
Flags: blocking-seamonkey2.0a1?
not going to block on this, but we might take a patch
Flags: blocking-seamonkey2.0a1? → blocking-seamonkey2.0a1-
Does this apply to Firefox as well, or should I open a separate bug?
Flags: wanted-seamonkey2?
I guess you should open a Firefox bug, blocking this one.
Summary: [RFE] Prioritize first tab in loading bookmark groups. → Prioritize first tab in loading bookmark groups
I think bug 514490 will fix this for Firefox.
Depends on: 514490
2.0 is now "feature complete", please renominate if you think it is appropriate.
Flags: wanted-seamonkey2.0? → wanted-seamonkey2.0-
Depends on: 313291
Still valid request
Depends on: 257453
Whiteboard: [2012 Fall Equinox]
"WONTFIX"?

"WONTFIX"?
Yes.

Bookmark groups are dead. Last ancient traces where removed in Bug 1607023 for SeaMonkey. If I load a folder with many tabs from the 2.53.1 library first tab is selected and I don't see a problem. If there still is one please file a new bug against SeaMonkey.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.