63782 - context menu for reload button

Status: NEW

(SeaMonkey :: UI Design, enhancement)

Description

[Henrik Gemal]

If your right click on the reload button a context menu should appear with a 
menuitem to "force" reload. Just like if you would shift reload.

Comment 1

[Cormac F]

You could add some other options to such a context menu, perhaps:
 - select specific frame to reload
 - reload all images. sometimes all the images don't load correctly, or only
half appear. v. annoying
 - reload all embedded components (flash movies, applets, etc.)
 - stop refresh (if the page automatically reloads itself through scripting or
http headers or whatever)

they're just off the top of my head, i'm sure there are a load of potential
enhancements.
This menu should be accessible through right click and by clicking on an arrow
like the back button history list.

Comment 2

[Matthew T (active 1999-2002)]

Recommend wontfix. These items (unlike the items in the Back and Forward menus) 
won't be used nearly often enough to deserve toolbar menu items.

Comment 3

[:deanis74]

I like the original idea of having a context menu with Reload (default), Force 
Reload, and maybe Reload Frame.  It's easier to explain this to a novice user 
than holding down Shift while clicking the Reload button.

Comment 4

[timeless]

context menus are skin specific. If we do this, we should just have a menu 
inside the button. If a skin likes drop down lists [like back/forward] then it 
does that. if it decides to do nothing then nothing, if it likes context then 
context.

And if people don't like a skin they don't have to use it.  Classic should 
probably support both dropdown and context.  [notable exception from 
nc4messenger: right click file button does not popup menu]

Comment 5

[Marcia Knous [:marcia]]

Netscape nav triage team: as per Alec Flett's pre-triage recommendation, this 
bug is nsbeta1-.

Comment 6

[Paul Chen]

Marking nsbeta1- bugs a future

Comment 7

[Blake Ross]

I agree with Matthew; these options won't be used enough to warrant such a 
prominent menu. Marking wontfix.

Comment 8

[Henrik Gemal]

...:( I would like to have a "mouse way" to do force reload.

Comment 9

[sairuh (rarely reading bugmail)]

v

Comment 10

[:deanis74]

I disagree.  If someone wants to add a context menu in for the button, let them.
 Reopening.

Comment 11

[:deanis74]

...marking as an RFE and assigning to nobody.

Comment 12

[Blake Ross]

That is terrible reasoning.  I shudder to think of what Mozilla would look like
today if everyone with an idea had a cvs account, but I have a pretty good idea.

This should not be done because:

A) It's not discoverable.  Why would anyone right click on the Reload button at
random?  It seems as useful as a hidden pref -- that is, more "stuff" added to
Mozilla for the benefit of an extremely tiny segment of users.  What would make
it discoverable is added the arrow and making it a dual menubutton, and then you
get into the whole "is this something the user cares about?" discussion, the
answer to which, I think, is no.

B) We should probably show a toolbar show/hide/customize context menu like IE,
Microsoft Office, and many other apps these days.

Please do not reopen wontfix bugs and reassign them to [e-mail]. 
[e-mail] is not a panacea, it is a place for bugs that module owners
don't think they'll ever fix, but they'd gladly accept a patch if someone
submitted it.  It should not be looked at as a dumping ground.  As we approach
1.0, and just in general, we need to ascertain that we have a database full of
valid, tangible bugs and requests for enhancements.  Bugs that no one is being
held accountable for, that are unlikely to ever be resolved/fixed even if a
patch comes in, are just bloating the database and slowing down queries.

Please *do* reopen wontfix bugs if you strongly disagree with the decision,
explaining why you disagree.

Comment 13

[:deanis74]

"Please do not reopen wontfix bugs and reassign them to [e-mail]. 
[e-mail] is not a panacea, it is a place for bugs that module owners
don't think they'll ever fix"

That's what I thought this bug was.  If there's a better assignee to give this
to for re-evaluation, I'm open to it.

"We should probably show a toolbar show/hide/customize context menu like IE,
Microsoft Office, and many other apps these days."

When a completely customizable toolbar comes around, I would consider marking
this as won't fix.

"Please *do* reopen wontfix bugs if you strongly disagree with the decision,
explaining why you disagree."

See comment 3, for a start.

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

What about not making this a context menu, but a dropdown menu? This would
improve discoverability a lot, and other buttons already have such menus. (Back,
Forward, Print)

Comment 15

[bugs]

It would be a good idea to extend the reload button to a dropdown (like Back and
Forward), because it will allow more fine-grained "reloading". Sometimes it
could be helpful in cases like bug 101013 when Mozilla displays the same static
page differently each time...
I think we should write a list of the possibly useful reload options like:

-Refresh: Does everything it would when loading the page, but without network
activity, so it wouldn't try loading broken images again. There could be a
conflict with disabled cache.

-Reopen page (The same as pressing enter again in the URL bar, use objects in
the cache, and fetch the missing ones)

-Reload text (Ignore HTML in the cache, but use it for other objects)

-Reload graphics (Use the cache for the HTML, but not for other objects)

-Reload page (ignore everything in the cache)

-Force proxy reload (use Pragma: no-cache)

The could be an additional option to use the Expires header, so only the expired
objects are reloaded, but I think it should be handled by the Reopen page option.

Feel free to add options to the list, and save the opposing reasons for later,
when we start compacting them if we exhausted the possibilities.

Comment 16

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 17

[zug_treno]

(In reply to comment #14)
> What about not making this a context menu, but a dropdown menu? 

(In reply to comment #15)
> Feel free to add options to the list, and save the opposing reasons for later,
> when we start compacting them if we exhausted the possibilities.

See bug 182653, duplicate of/related to this bug?