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.
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.
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.
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.
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]
Netscape nav triage team: as per Alec Flett's pre-triage recommendation, this bug is nsbeta1-.
Marking nsbeta1- bugs a future
Target Milestone: --- → Future
I agree with Matthew; these options won't be used enough to warrant such a prominent menu. Marking wontfix.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX
...:( I would like to have a "mouse way" to do force reload.
Status: RESOLVED → VERIFIED
I disagree. If someone wants to add a context menu in for the button, let them. Reopening.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
...marking as an RFE and assigning to nobody.
Assignee: ben → nobody
Status: REOPENED → NEW
Summary: context menu for reload button → [RFE] context menu for reload button
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 firstname.lastname@example.org. email@example.com 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.
"Please do not reopen wontfix bugs and reassign them to firstname.lastname@example.org. email@example.com 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.
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)
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.
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: normal → enhancement
Summary: [RFE] context menu for reload button → context menu for reload button
(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?
You need to log in before you can comment on or make changes to this bug.