User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a2) Gecko/20111220 Firefox/10.0a2 Build ID: 20111220042029 Steps to reproduce: Clicked a link too soon after alt-tabbing. / accidentally activated ALT just before or while clicking a link. Actual results: The link was saved (downloaded). Expected results: The link should have opened.
Comment on attachment 584346 [details] [diff] [review] patch 0.1 I'd reverse the meaning of the pref and rename it "browser.ignoreLinkAltClick" or some such. But this pref isn't very valuable as a hidden pref. If we think accidental alt+clicks are a common user annoyance, we should be addressing the problem in a way that will benefit users who have no idea what about:config is.
Attachment #584346 - Flags: feedback?(gavin.sharp) → feedback+
(In reply to Gavin Sharp (use email@example.com for email) from comment #2) > as a hidden pref. If we think accidental alt+clicks are a common user > annoyance, we should be addressing the problem in a way that will benefit > users who have no idea what about:config is. Sure, I think that implies that we want some UX team input on this (adding the appropriate semaphores) issue, at which point we're just haggling over the default value for the preference. I don't think we want to add more options into the already laden Tabs pane, but I'd be down with off-by-default and making it something the more technically inclined can re-enable.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Gavin Sharp (use firstname.lastname@example.org for email) from comment #2) > If we think accidental alt+clicks are a common user > annoyance, we should be addressing the problem in a way that will benefit > users who have no idea what about:config is. Agreed. I think alt-clicking to download is something that shouldn't be the default, as it's not very obvious to people that it will download what is clicked. Sounds like changing the default behavior and introducing a pref for the people that rely on this is the way to go. (…and even possibly making the world's simplest extension to flip that pref :)
+ reversed the meaning of the preference. + alt-clicking to download is no longer the default. I have attached a bootstrapped extension which toggles the preference, and also resets it on disable/uninstall.
+ reverse reversed the meaning
Attachment #601364 - Flags: review?(gavin.sharp) → review+
This will need some additional test fixes before it can land (spoke to Johan on IRC). I've also pushed this to try to weed out any other potential failures.
https://hg.mozilla.org/integration/mozilla-inbound/rev/5c84280687df Also, to make life easier for the people checking your patches in for you, please follow the below directions for future patches you submit. Thanks! https://developer.mozilla.org/en/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F
Wow, awesome midair collision. Backing out...
Try run for 6a25d9512584 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=6a25d9512584 Results (out of 215 total builds): success: 166 warnings: 47 failure: 1 other: 1 Builds (or logs if builds failed) available at: http://email@example.com
So based on the try results, it looks like you have two tests that need updating: browser/base/content/test/browser_contentAreaClick.js browser/base/content/test/browser_locationBarCommand.js The easiest thing to do is probably to just have those tests set the pref to true temporarily, similar to how browser/base/content/test/browser_urlbarAutoFillTrimURLs.js sets browser.urlbar.trimURLs.
(In reply to Ryan VanderMeulen from comment #9) > https://hg.mozilla.org/integration/mozilla-inbound/rev/5c84280687df > > Also, to make life easier for the people checking your patches in for you, > please follow the below directions for future patches you submit. Thanks! > https://developer.mozilla.org/en/ > Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check- > in_for_me.3F Apologies, fixed. Updated the following tests: browser/base/content/test/browser_contentAreaClick.js browser/base/content/test/browser_locationBarCommand.js
Comment on attachment 601727 [details] [diff] [review] patch 0.5 Looks good, but you don't need the try/catch around the calls to clearUserPref in browser_contentAreaClick.js. r=me with those removed.
Attachment #601727 - Flags: review?(gavin.sharp) → review+
+removed all try/catch
Attachment #601735 - Flags: review?(gavin.sharp) → review+
Whiteboard: [autoland:-b do -p all -u all -t none]
Whiteboard: [autoland:-b do -p all -u all -t none] → [autoland-in-queue]
Autoland Patchset: Patches: 601735 Branch: mozilla-central => try Destination: http://hg.mozilla.org/try/pushloghtml?changeset=6d2a44f16bcd Try run started, revision 6d2a44f16bcd. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=6d2a44f16bcd
Try run for 6d2a44f16bcd is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=6d2a44f16bcd Results (out of 219 total builds): exception: 2 success: 175 warnings: 40 failure: 2 Builds (or logs if builds failed) available at: http://firstname.lastname@example.org
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: Add preference for disabling ALT-clicks to save links. → add preference for disabling alt+click or alt+enter to save pages
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 13
Summary: add preference for disabling alt+click or alt+enter to save pages → add preference for disabling alt+click or alt+enter to save pages, and disable it by default
Summary: add preference for disabling alt+click or alt+enter to save pages, and disable it by default → Add preference for disabling alt+click or alt+enter to save links, and disable it by default
Just quick summary of current state (for random googlers): - config pref key is "browser.altClickSave", - off by default, so no action needed after upgrade to make it work, - planned for Fx 13, - already present in Nightlies.
(In reply to Michal Čaplygin [:myf] from comment #21) > Just quick summary of current state (for random googlers): > - config pref key is "browser.altClickSave", > - off by default, so no action needed after upgrade to make it work, It's not clear what "it" you mean in "make it work". To be clear: alt+click/alt+enter to save was disabled by default by this patch, and users who wish to keep that functionality need to manually adjust the (hidden) preference.
Summary: Add preference for disabling alt+click or alt+enter to save links, and disable it by default → disable alt+click or alt+enter to save links by default (with a hidden preference to re-enable)
Beta merges in 11 days and and user docs are still needed! Most imageboard users use this feature all the time, so it might be worth mentioning this in the release notes.
Please restore the 'alt click to save' feature by default in the next version of firefox. The justification for removing this was pretty weak, and you are doing nothing but making it harder for casual users of firefox to download files. Advanced users who want to remove this feature can do so from the config page, but there really is no reason to remove this feature for the rest of us. If this feature is not restored by FF14, I will officially be recommending chrome to my customers over firefox, as they still retain this feature.
The justification for removing this makes very little sense indeed. It applies equally well to why Ctrl+Click should also be removed. Can this default be reconsidered? I could open a separate bug for that.
It seems to me that the fix completely missed the problem. The underlying problem has not been addressed and it still there. The underlying problem is that a single click, with no Ctrl or Alt pressed, can be misinterpreted by Firefox as Alt+Click or Ctrl+Click when it is running slow/under stress/lagging. Firefox should not misinterpret input in this way. Should I open a new bug for this and describe the underlying problem in more detail?
I agree with the others that this change was poorly thought-out and incredibly weakly justified. It should be restored to the previous functionality with a "disable altClick download" pref. As for the argument that holding a MODIFIER key will MODIFY the click behavior -- that's absurd. How that pitiful reason resulted in the *removal* of a longstanding and often-used feature of the browser is incredible. Please reconsider this shortsighted action.
Filed bug 876546.
I have seen countless sites, and overheard dozens of intro computing classes (in several schools and training centres), where alt+click-to-download was explicitly directed. I’ve even taught the feature when volunteering in such classes. Now, non-technical persons, who are typically confused, frustrated, or scared by anything to do with <about:config>, ask teachers, trainers, tutors, and support technicians why alt+click-to-download is broken. Are you sure this was the best resolution? (As an aside, I would suggest that the only features which should be hidden behind <about:config> are those which are only expected to be sought by the sort of users who understand <about:config>.) As an analogy to the alternative solution I’ll suggest below, consider this difference: If, while using another program (perhaps a game with “WASD” navigation), I hold a letter-key, say “w”, and then click in this very textarea in Fx: then, no “w”s are inserted here. The fact that I am holding "w" while focused on this textarea is irrelevant to the textarea, because the “w”-keydown preceded, rather than following, the coming into foreground of the window (in which this textarea is in focus). However, if I (first) focus on div#add_comment, which is ancestral to this textarea, (second) press-and-hold “w”, and third focus this textarea, then a run of “w”s begins being inserted at the insertion point. If a common mode of user error is to accidentally keep alt held down while clicking a link, after using alt+tab to switch windows, then perhaps alt+click-to-download could be suppressed when the window did not receive the keydown event which led to alt being held during the click event. In that case, when the window is brought into foreground via alt+tab, since the window was in background before tab-keydown, and alt-keydown necessarily preceded tab-keydown, the window will not have received the alt-keydown; thus, alt’s depressed state can be taken as intended for the OS’s window manager, and considered irrelevant to the link’s interpretation of the click. I believe this would resolve the conflict between the two concerns, without burying a feature used by non-technical users in a place where non-technical users are wary to go.
You need to log in before you can comment on or make changes to this bug.