Closed Bug 171096 Opened 22 years ago Closed 10 years ago

Add "prefetch link" to link context menu

Categories

(Core :: Networking, enhancement)

enhancement
Not set
normal

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
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
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?
-> 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.