Note: There are a few cases of duplicates in user autocompletion which are being worked on.

disable alt+click or alt+enter to save links by default (with a hidden preference to re-enable)

RESOLVED FIXED in Firefox 13

Status

()

Firefox
Keyboard Navigation
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: Johan C, Assigned: Johan C)

Tracking

({relnote, user-doc-needed})

Trunk
Firefox 13
relnote, user-doc-needed
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 5 obsolete attachments)

(Assignee)

Description

6 years ago
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.
(Assignee)

Comment 1

6 years ago
Created attachment 584346 [details] [diff] [review]
patch 0.1

initial patch
(Assignee)

Updated

6 years ago
Attachment #584346 - Flags: feedback?(gavin.sharp)
(Assignee)

Updated

6 years ago
Attachment #584346 - Flags: feedback?(gavin.sharp)
(Assignee)

Updated

6 years ago
Attachment #584346 - Flags: feedback?(gavin.sharp)
(Assignee)

Updated

6 years ago
Assignee: nobody → johan.charlez
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 gavin@gavinsharp.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
Keywords: uiwanted
(In reply to Gavin Sharp (use gavin@gavinsharp.com 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 :)
Keywords: uiwanted
(Assignee)

Comment 5

6 years ago
Created attachment 597454 [details] [diff] [review]
patch 0.3

+ 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.
Attachment #584346 - Attachment is obsolete: true
Attachment #597454 - Flags: feedback?(gavin.sharp)
(Assignee)

Comment 6

6 years ago
Created attachment 597458 [details]
extension that toggles the pref
Attachment #597458 - Flags: feedback?(gavin.sharp)
(Assignee)

Comment 7

6 years ago
Created attachment 601364 [details] [diff] [review]
patch 0.4

+ reverse reversed the meaning
Attachment #597454 - Attachment is obsolete: true
Attachment #597454 - Flags: feedback?(gavin.sharp)
Attachment #601364 - Flags: review?(gavin.sharp)
Attachment #601364 - Flags: review?(gavin.sharp) → review+

Updated

6 years ago
Keywords: checkin-needed
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.
Keywords: checkin-needed
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...
Backed out.
https://hg.mozilla.org/integration/mozilla-inbound/rev/d71e85f35751

Comment 12

6 years ago
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://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/gsharp@mozilla.com-6a25d9512584
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.
(Assignee)

Comment 14

6 years ago
Created attachment 601727 [details] [diff] [review]
patch 0.5

(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
Attachment #601364 - Attachment is obsolete: true
Attachment #601727 - Flags: review?(gavin.sharp)
Attachment #597458 - Flags: feedback?(gavin.sharp)
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+
(Assignee)

Comment 16

6 years ago
Created attachment 601735 [details] [diff] [review]
patch 0.5.1

+removed all try/catch
Attachment #601727 - Attachment is obsolete: true
Attachment #601735 - Flags: review?(gavin.sharp)
Attachment #601735 - Flags: review?(gavin.sharp) → review+
Whiteboard: [autoland:-b do -p all -u all -t none]

Updated

6 years ago
Whiteboard: [autoland:-b do -p all -u all -t none] → [autoland-in-queue]

Comment 17

6 years ago
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

Comment 18

6 years ago
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://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/autolanduser@mozilla.com-6d2a44f16bcd

Updated

6 years ago
Whiteboard: [autoland-in-queue]
Keywords: checkin-needed
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
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac7a006e4420
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/ac7a006e4420
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 13

Updated

6 years ago
Keywords: user-doc-needed
Version: 10 Branch → Trunk
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

Updated

5 years ago
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.
Keywords: relnote
Blocks: 762466
(Assignee)

Updated

5 years ago
Attachment #597458 - Attachment is obsolete: true

Comment 24

5 years ago
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.

Comment 25

4 years ago
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.

Comment 26

4 years ago
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?

Comment 27

4 years ago
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.

Comment 28

4 years ago
Filed bug 876546.

Comment 29

4 years ago
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.