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).
Assignee: asa → blakeross
Component: Browser-General → XP Apps: GUI Features
QA Contact: doronr → sairuh
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.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, ui
OS: Linux → All
Hardware: PC → All
claudius <washes hands> since the failure is only within the context menu, bouncing back. sorry for spam
QA Contact: claudius → sairuh
so not a regression, enhancement request.
Severity: minor → enhancement
Keywords: regression → helpwanted
*** 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?
Summary: Right-click reload & reload button not the same → shift+click on "reload" in context menu to force-reload frame
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.
Severity: enhancement → normal
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)
Summary: shift+click on "reload" in context menu to force-reload frame → hift+contextmenu-"Reload" does not Force-Reload
Summary: hift+contextmenu-"Reload" does not Force-Reload → shift+contextmenu-"Reload" does not Force-Reload
Assignee: blaker → cbiesinger
Status: ASSIGNED → NEW
Priority: -- → P1
Target Milestone: Future → mozilla0.9.9
damn, blake was right... event.shiftKey is always false for a <menuitem> I filed bug 126189 about this issue.
Depends on: 126189
tm->future until 126189 is fixed
Target Milestone: mozilla0.9.9 → Future
*** Bug 137724 has been marked as a duplicate of this bug. ***
16 years ago
Priority: P1 → P5
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.
Assignee: cbiesinger → blaker
QA Contact: sairuh → paw
*** Bug 290729 has been marked as a duplicate of this bug. ***
Assignee: bross2 → guifeatures
QA Contact: pawyskoczka
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
Closing as WORKSFORME. Fixed as part of Bug 529240.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.