From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19 i686; en-US; rv:0.9) Gecko/20010505 BuildID: 2001050521 If one shift-clicks the reload button in the browser, one gets a forced refresh header in one's request to force proxies to recheck documents. If one right-clicked the document then held shift while clicking reload from the context menu in 0.8, it did the same thing. In 0.9, it does not ... it does a normal refresh. Reproducible: Always Steps to Reproduce: n/a

probably xp apps gui features.... Did this really work in 0.8???? (I have a hard time believing we actually test for "shift" on context menu clicks).

I've used this feature in every version of Netscape I've had, and with Mozilla and a client's website I've been working on in 0.8 and 0.81, this function worked as well as far as I can remember. The fact that I'm somewhat dismayed that it no longer works indicates to me that it did before ;-) but I can check an old copy of 0.8 to check.

I tested against 0.8. What has changed is that in 0.8, all reloads were forced refreshes (reported by Squid as TCP_CLIENT_REFRESH_MISS). In 0.9 it seems that quick refreshes (has this changed? no? ok.) have been implemented for all reloads except shift-clicking the reload button on the toolbar. So in 0.8, shift wasn't detected on the context menu but it wasn't relevant because all reloads behaved the way a shift-reload should.

Makring NEW.

claudius <washes hands> since the failure is only within the context menu, bouncing back. sorry for spam

so not a regression, enhancement request.

*** Bug 80565 has been marked as a duplicate of this bug. ***

Uh...Matthew? Shift-clicking on the menuitem? (To tell the truth, we can't do or really shouldn't be doing that.)

If we "shouldn't" be doing this, then how am I to force a refresh on a page within a frame? Currently, I have to do a "view only current frame" then do a shift-reload on the title-bar, then hit "back".

we have a "reload frame" context menuitem - perhaps make it work as a shift reload?

Does anyone see any detrimental effects to setting the right-click (context menu) "reload frame" option to always doing a conditional verification of the page content? Is there a bug entry of any form for how Mozilla will be handling caching of pages in general? That would be a good place for a lot of this discussion. It seems somewhat obvious that Mozilla ought to be a good Internet citizen and do conditional refreshes based on Etags, etc. using HTTP/1.1 where possible, so the refresh cases I'm dealing with would dissapear if that was done properly on page and frame reloads in the first place. To be terribly verbose, could we perhaps have multiple items with different meanings? "Conditional Refresh" vs. "Reload from Server" (but shorter ;-).

I agree with Michael and Doron that it would make sense for the `Reload Frame' context menu item to always do a forced refresh of the frame -- since there isn't another convenient way to offer forced frame refreshes. (Try saying that ten times fast.) We're hardly going to be killing the world's proxy caches by doing that only for this obscure menu item. I disagree with Michael on everything else. :-) Bugzilla is not a good place for a lot of *any* discussion; and separate `Conditional Refresh' and `Reload from Server' context menu items would be more confusing than useful.

Thank-you Matthew for that support -- I was simply thinking outloud about whether it was possible or even desirable to properly indicate that the two refreshes (the toolbar vs. the context menu) don't do the same thing. Re: discussion on bugzilla; when there are quicklinks between threads on the newsgroups and bugzilla, then discussions will happen in the newsgroups. Until then, people have their discussions in bugzilla (where, you're correct, they ought not be).

*** Bug 92885 has been marked as a duplicate of this bug. ***

I do think that this is a bug - I expect that any menu items and buttons with the same name also behave the same. Expecially in such a case, where the "malfunction" is not directly discoverable, but with consequences.

It _is_ a bug that functionality is available but only under certain conditions and hidden from the user. I've filed bug 98922 to request the additional menu item.

Clarifying SUMMARY a bit more (hopefully)

taking bug

damn, blake was right... event.shiftKey is always false for a <menuitem> I filed bug 126189 about this issue.

tm->future until 126189 is fixed

*** Bug 137724 has been marked as a duplicate of this bug. ***

is this even needed?

doron, do you mean that this bug should not be fixed, or that bug 126189 does not need to be fixed for this one? If the latter, why not? If I can't find out if the shift key is pressed, I can't do a force reload if it's pressed.

It was suggested at one point that the context-menu reload always be a forced-refresh. Is this a valid idea?

I am talking about the this bug, if someone wants to shift reload, use the toolbar button. (how long till someone mentions browsing without the toolbar?) So perhaps make the reload frame always a shift-reload?

doron, this bug is about user expectations. For example, people tell other people to "SHIFT-reload". They don't say "but don't use the context menu".

I have learned that UI patches are not wanted in this project. reassigning to default owner.

*** Bug 290729 has been marked as a duplicate of this bug. ***

Filter "spam" on "guifeatures-nobody-20080610".

Closing as WORKSFORME. Fixed as part of Bug 529240.