Closed
Bug 171096
Opened 22 years ago
Closed 10 years ago
Add "prefetch link" to link context menu
Categories
(Core :: Networking, enhancement)
Core
Networking
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: bwucke+bug, Unassigned)
Details
The worst bane of the "prefetch" feature is that it fetches pages that are never visited. The feature of prefetching "next", "last" and "menu" documents is nice, but will be really rarely used (few pages utilise this feature) ( Bug 12274 , Bug 166647 ) In the other hand, users VERY often open multitude of windows/tabs just to prefetch some page for viewing, before finishing reading the previous one. What, if the prefetch mechanism was brought straight to the user's UI, no more watching the blank page before the contents load, no more need for "open in new window" and just when the new tab is loaded, close the previous one. Expected behavior: 1. Just right-click on a link and select (or maybe middle-click or control-click - add option to prefs, about possible behavior of link when middle clicked - "preload") 2. Continue wieving your current page. You may add other links to "preload" queue. 3. Left-click on the link after some time. The page is loaded from cache, where it got saved by the preload mechanism.
uid is being phased out.
Assignee: mpt → darin
Component: User Interface Design → Networking: HTTP
QA Contact: zach → httpqa
Comment 2•22 years ago
|
||
i'm not so sure about this idea... accepting for now, but that doesn't mean much.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Future
Reporter | ||
Comment 3•22 years ago
|
||
Sure... There are pluses and minuses. - to make it work properly we'd have to enhance the prefetch mechanism - loading anything stops prefetching instead of suspending it, stuff partially prefetched is discarded when the page is loaded, etc. - Cluttering context menu. It's not rubber and we don't want to add scroll arrows to it ;) But I think replacing "open link in new [tab|window]" could be replaced with one prefs-selectable item (people usually use either of the options, not both anyway) and then prefetch could be yet another selectable item. Definitely ->future though and subject for some other bug ("unclutter context menu") - Work is work. The time could be sacrificed on something else, maybe more important. - Slight bloat. Besides extending prefetch mechanism a bit (should be done anyway, current is just a simple hack) we add quite a few GUI items to make use of that. Results in overall performance decrease but still pays back more than costs (surely prefetch takes less CPU time and RAM than opening a new window/tab) + Definitely best choice between "wait for new page to load" and "prefetch all". unless we can read in user's mind. (we can't. Some other company thinks they can but that yields no good ;) + Original alternative to "multi-tab/multi-window" browsing. (no other browser has this AFAIK). + Much of the stuff is here already (bones of prefetch, middle-click behavior selector). Just hook them up and tweak some. + Encourage users to give up the evil "prefetch all" accelerators. + Increase in "subjective" performance feel. (all stuff like javascripts, flash etc starts running when the page is opened, while previous page with its active contents is unloaded. No 10 shockwave banners in 10 open windows playing simultaneously, slowing down the browser to crawl. Page loaded but not rendered until it's needed.) Anyone else to submit other problems I missed?
Comment 4•18 years ago
|
||
-> default owner
Assignee: darin → nobody
Status: ASSIGNED → NEW
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Target Milestone: Future → ---
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•