Closed Bug 141615 Opened 20 years ago Closed 2 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-
Duplicate of this bug: 313291
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: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.