User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0 (Beta/Release) Build ID: 20130326150557 Steps to reproduce: I held down F5. Actual results: My web server got flooded with identical requests. Expected results: It should perform one refresh per keydown, and ignore the keyboard repeat setting.

It seems outrageous that most web browsers, including Firefox, have a built-in fully automatic denial-of-service attack feature in the F5 key. If people want a rapid fire of refreshes, they should put the effort in and pound their F5 key manually!

See also: bug 224026 (very old though).

I don't agree that this bug is a duplicate! While these issues are tangentially related, this is a problem specifically unique to the reload/refresh functionality.

(In reply to Simon Wright from comment #4) > I don't agree that this bug is a duplicate! While these issues are > tangentially related, this is a problem specifically unique to the > reload/refresh functionality. Keybindings are implemented in a fairly generic fashion. If we wanted to fix it as you suggest, i.e., listen for actual keypresses rather than some arbitrary delay (e.g. don't refresh more than once every 5 seconds), we would need to fix bug 71074, that is why I marked it as a duplicate. The consequences you see (i.e. a flood on your webserver) may be unique to F5, but similarly unhappy things happen if you were to hold down eg. ctrl+n to create new windows. The ground problem is how we deal with keyboard shortcuts, and hence this should be a duplicate, IMO.

I agree with Simon that this is a special case. Independent of how it's called (F5, ctrl+R, refresh button, context menu, anything else I've missed), the refresh function should in some way limit the number of requests it sends. The refresh button currently implements this in a way, by changing to a stop button while the request is running. Perhaps rather than an outright rate limit, it should be implemented by only sending another request once the current top-level request in the active tab (i.e. the request for the page itself, as opposed to resources such as stylesheets/scripts/images) has finished; this could be as simple as adding an "if (requestRunning) return;" at the top of the refresh function (note: that's pseudocode - I haven't looked at the relevant Firefox code, but don't expect that this bears any resemblance to it). Such a change would have no bearing on #71074 - and would also cover the case of actual repeated keypresses (as opposed to auto-repeat). If (for example) a request is taking a long time to complete, and for some reason you absolutely must refresh the page right now (rather than waiting for it to finish loading), you could always hit stop (ESC, button click, etc) and then refresh. In addition to resolving the immediate issue of the flood of requests, this suggestion may also help improve perceived performance in some cases: if a page is taking a while to load, some users will (out of frustration) start hitting the F5 key, thus triggering additional requests for the slow page. I've never seen anyone *hold* F5 in frustration, but I've seen them repeatedly hit it with increasing frequency. If hitting F5 while the top-level request is still running did nothing, rather than triggering a new request, they'll get the page (eventually) loading from their original request rather than bogging the server down with more requests for the same page.

(In reply to Paul Nicholls from comment #6) > I agree with Simon that this is a special case. Independent of how it's > called (F5, ctrl+R, refresh button, context menu, anything else I've > missed), the refresh function should in some way limit the number of > requests it sends. The refresh button currently implements this in a way, > by changing to a stop button while the request is running. > > Perhaps rather than an outright rate limit, it should be implemented by only > sending another request once the current top-level request in the active tab > (i.e. the request for the page itself, as opposed to resources such as > stylesheets/scripts/images) has finished; this could be as simple as adding > an "if (requestRunning) return;" at the top of the refresh function This wouldn't work because in some cases requests time out or otherwise take a long time to complete. That will take a maximum of 5 minutes. Not allowing people to refresh before then (if they know they fixed whatever caused the request to just sit there) would just mean the browser would appear "broken". And before you suggest we should make it take less than 5 minutes - we only recently made the 5 minutes a hard limit, and web developers who want to e.g. debug their PHP code invoked from browser requests were in absolute uproar about that change. I agree with my previous comments. This is a duplicate.

(In reply to :Gijs Kruitbosch from comment #7) > (In reply to Paul Nicholls from comment #6) > > I agree with Simon that this is a special case. Independent of how it's > > called (F5, ctrl+R, refresh button, context menu, anything else I've > > missed), the refresh function should in some way limit the number of > > requests it sends. The refresh button currently implements this in a way, > > by changing to a stop button while the request is running. > > > > Perhaps rather than an outright rate limit, it should be implemented by only > > sending another request once the current top-level request in the active tab > > (i.e. the request for the page itself, as opposed to resources such as > > stylesheets/scripts/images) has finished; this could be as simple as adding > > an "if (requestRunning) return;" at the top of the refresh function > > This wouldn't work because in some cases requests time out or otherwise take > a long time to complete. That will take a maximum of 5 minutes. Not allowing > people to refresh before then (if they know they fixed whatever caused the > request to just sit there) would just mean the browser would appear > "broken". And before you suggest we should make it take less than 5 minutes > - we only recently made the 5 minutes a hard limit, and web developers who > want to e.g. debug their PHP code invoked from browser requests were in > absolute uproar about that change. > > I agree with my previous comments. This is a duplicate. > > *** This bug has been marked as a duplicate of bug 71074 *** It sounds to me as though you're talking about power users / developers ("if they know they fixed" the problem). I'd have thought that such users could figure out to stop the request and then start a new one - especially if there has been no visual or other indication that a reload has been initiated, or if there was a subtle visual hint that the refresh was NOT initiated, such as a struck-through refresh symbol appearing briefly. All users could be introduced to the change by a friendly message appearing the first few times they hit refresh while that tab's top-level request is still running - "This page is still loading. If you'd like to request it again, please stop the current request first", or something along those lines. If you're worried about potential backlash from web developers, how about adding a new setting to about:flags to allow them to opt out of the new behaviour? If you still insist on treating it as a duplicate, could there please at least be some kind of commitment to addressing bug 71074? Closing this bug as a duplicate of a 13-year-old one doesn't instill confidence that the situation will be addressed any time soon.

> If you still insist on treating it as a duplicate, could there please at least be some kind of commitment to addressing bug 71074? Closing this bug as a duplicate of a 13-year-old one doesn't instill confidence that the situation will be addressed any time soon. The resolution could be replaced with "Depends: 71074". If you vote for that bug (voting may not be available to new users), that might instill confidence into potential fixers?

(In reply to Paul Nicholls from comment #8) > (In reply to :Gijs Kruitbosch from comment #7) > > (In reply to Paul Nicholls from comment #6) > > > I agree with Simon that this is a special case. Independent of how it's > > > called (F5, ctrl+R, refresh button, context menu, anything else I've > > > missed), the refresh function should in some way limit the number of > > > requests it sends. The refresh button currently implements this in a way, > > > by changing to a stop button while the request is running. > > > > > > Perhaps rather than an outright rate limit, it should be implemented by only > > > sending another request once the current top-level request in the active tab > > > (i.e. the request for the page itself, as opposed to resources such as > > > stylesheets/scripts/images) has finished; this could be as simple as adding > > > an "if (requestRunning) return;" at the top of the refresh function > > > > This wouldn't work because in some cases requests time out or otherwise take > > a long time to complete. That will take a maximum of 5 minutes. Not allowing > > people to refresh before then (if they know they fixed whatever caused the > > request to just sit there) would just mean the browser would appear > > "broken". And before you suggest we should make it take less than 5 minutes > > - we only recently made the 5 minutes a hard limit, and web developers who > > want to e.g. debug their PHP code invoked from browser requests were in > > absolute uproar about that change. > > > > I agree with my previous comments. This is a duplicate. > > > > *** This bug has been marked as a duplicate of bug 71074 *** > > It sounds to me as though you're talking about power users / developers ("if > they know they fixed" the problem). Not really. If you attempt to access a website that should work, and only then realize you need to plug in the ethernet cable or go through the hotel wifi signup, non-power-users do fall in the group who knows when to try again. > I'd have thought that such users could > figure out to stop the request and then start a new one - especially if > there has been no visual or other indication that a reload has been > initiated, or if there was a subtle visual hint that the refresh was NOT > initiated, such as a struck-through refresh symbol appearing briefly. All > users could be introduced to the change by a friendly message appearing the > first few times they hit refresh while that tab's top-level request is still > running - "This page is still loading. If you'd like to request it again, > please stop the current request first", or something along those lines. All of these suggestions represent a terrible cost/benefit ratio. We'd have to purposely design the "solution", implement it, write tests, translations, etc. It'd cost us continually in user annoyance and/or "why doesn't it just do what I want" negative user experience, and we'd diverge from how other browsers work. The only benefit is that it stops... a theoretical DoS attack where users all bond together and smash F5 on their keyboard? Not only does this sound preposterous, there's no documented example of it ever happening. That is entirely expected, because if you were going to DoS anything, you'd use something more efficient than human beings smashing F5 in their webbrowser. > If you still insist on treating it as a duplicate, could there please at > least be some kind of commitment to addressing bug 71074? Closing this bug > as a duplicate of a 13-year-old one doesn't instill confidence that the > situation will be addressed any time soon. The likelihood of bug 71074 being addressed isn't relevant to whether or not this is a duplicate, nor will not marking this as a duplicate make that bug be addressed sooner - if anything, it works the other way around, and the dupe will help make clear that bug 71074 should be fixed. It's a duplicate because this bug and the other bug describe the same underlying issue, which is about how Firefox treats keyboard shortcuts. Fixing bug 71074 would automatically fix this bug without any further work, and so a dependency isn't required either. I'm not in any position to give you a "commitment" as to when that bug gets addressed, nor would I be able to do that for this bug if I unduped them. As I've made clear above, I think the cost/benefit ratio of fixing this issue specifically is essentially terrible, and so you're better off waiting for bug 71074 to be fixed than the other way around.