Open Bug 740275 Opened 12 years ago Updated 2 years ago

Win7 "Select Folder" button on OS-native "Save All Attachments" dialogue has no access key character (and often inaccessible even with Enter)

Categories

(Thunderbird :: Mail Window Front End, defect)

11 Branch
All
Windows 7
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: brokenthorn, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access, Whiteboard: [invalid?])

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.83 Safari/535.11

Steps to reproduce:

Click Save All Attachments


Actual results:

If there is more than 1 file, the default Alt+S ("Save" button for the single file dialog, "Select Folder" for multiple files) shortcut doesn't work.


Expected results:

The dialog should have been confirmed.
(In reply to Paul-Sebastian Manole from comment #0)
I didn't know this keyboard shortcut exists before. Saving using the "Save All" button works for me though.

User Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
Application Build ID: 20120327115527
this is referred to as access key.
I'm not sure how it behaved previously
Severity: normal → minor
Summary: Regression: File dialog for Save All Attachments has no default keyboard shortcut → Regression: File dialog for Save All Attachments has no access key
I used keyboard shortcuts quite a lot. Previously, when you had to save attachments, if there was one attachment, clicking the Save button, opened a file save dialog where the default access key was Alt+S. Also previously, when you had to save attachments, if there were more than one file, clicking the Save All button (which is the same as the Save button, but now just reads Save All), opened a folder selection dialog with a folder tree without a default access key but pressing Enter on the selected folder confirmed the save dialog. Those were my two shortcuts that got me through a day of saving dozens of attachments (reports I get mailed in) to their correct places.

Please add an access key to maybe every default button on every modular dialog that TB has? I'd be very thankful! :)
(In reply to Magnus Melin from comment #4)
> That dialog is windows native code - i don't think it can really be changed.

I think Magnus is right. And because we use Windows native dialogue, access key behaviour is different (but access keys are available, and this bug is probably invalid, as I'll explain below).

Here's what I see on WinXP:

- After using "Save all" button from msg hdr, native "Browse for Folder" - "Save all attachments" dialogue pops up, with 3 buttons incl. "Make New Folder" button (slight variations are possible, I can't test on English version of Windows, so my buttons are in German).
- By default, Windows will *not* indicate access keys: To see your access keys, press ALT once: Access keys are now shown on Buttons: _M_ake New Folder.
If you memorize the access key, of course it will also work without prior indication, so when the "Browse for Folder" dialogue pops up, the following access keys are immediately available on WindowsXP:

Save All (for all attachments) ->
Access keys for native Windows "Browse for Folder" dialogue

Make New Folder: Alt+M
OK: Enter (*)
Cancel: Esc
(less important access keys are missing for Folder name input field, and the folder list; probably that's already missing in the native dialogue before we customize it).

*: where OK is equivalent to "Select this folder and save all files there"

Save As (for single or multiple attachments) ->
Access keys for native Windows "Save Attachment" dialogue

Save: Alt+S
Cancel: Esc
(and some more access keys present for the input fields)

Assuming that the same applies to Windows7 (access keys are present on both dialogues, but user needs to press ALT to see them), I think that makes this bug technically invalid.

History rant:

Reporter claims he was using Alt+S even for the "Save all [attachments]" case. That may not be technically true, but our UI has always been confusing in this corner. Both in TB2 and current release (TB11), when you manually select all attachments from the pane, somewhat absurdly we only offer "Save as" from context menu, which will show multiple instances of the native single-file "Save Attachment" dialogue for each single attachment (a legitimate use case; the absurdity is that you don't find "Save all" as an *alternative* in the context menu, that's Bug 466060, wrongly resolved fixed, see Bug 466060 Comment 42 and 45). So in TB2, and probably initial TB3, "Save all" -> "Browse for folder" was absurdly only available from context menu on attachment pane *whitespace*, and, more absurdly, only after *deselecting* all attachments. So practically it was undiscoverable until we introduced the "Save all" button. The native "Browse for folder" dialogue only has OK button to select folder, so the access key for that dialogue has always been "Enter", as opposed to Alt+S for the "Save" Button on the single-file "Save Attachment" dialogue. We have a number of bugs complaining about the shortcomings of using the native dialogues with less intuitive button captions etc.
Tested on Windows 7 Starter (sigh, that's my slowest machine...):

Save All (for all attachments) ->
Access keys for native Windows "Browse for Folder" dialogue

"Select Folder" button: Enter (no other explicit access key character provided)
Cancel: Esc
(no other access keys present, e.g. for other buttons like "New folder")

Save As (for single or multiple selected attachments) ->
Access keys for native Windows "Save Attachment" dialogue

Save: Alt+S (or Enter)
Cancel: Esc
(and some more access keys present for the input fields)

So for the problem described by reporter, he can use "Enter" as a consistent workaround access key for "Save attachment(s)" in both dialogues.
I suppose that reporter is right, there should be an access key Alt+S for the "Select Folder" button (because Enter will not work from all spots in the dialogue, and not in all situations); I further suppose that's a bug in the native dialogue, not our customization. So probably we can't fix it, which unfortunately would make this invalid.

(And as explained in the history rant of comment 5, this is not a regression.)
Component: General → Mail Window Front End
QA Contact: general → front-end
Hardware: x86_64 → All
Summary: Regression: File dialog for Save All Attachments has no access key → File dialog for Save All Attachments has no access key
Whiteboard: [invalid?]
Summary: File dialog for Save All Attachments has no access key → Win7 "Select Folder" button on OS-native "Save All Attachments" dialogue has no access key character (but usually accessible as default button with Enter)
(In reply to Paul-Sebastian Manole from comment #3)
> I used keyboard shortcuts quite a lot. Previously, when you had to save
> attachments, if there was one attachment, clicking the Save button, opened a
> file save dialog where the default access key was Alt+S. Also previously,
> when you had to save attachments, if there were more than one file, clicking
> the Save All button (which is the same as the Save button, but now just
> reads Save All), opened a folder selection dialog with a folder tree without
> a default access key but pressing Enter on the selected folder confirmed the
> save dialog. Those were my two shortcuts that got me through a day of saving
> dozens of attachments (reports I get mailed in) to their correct places.

Why "previously"? All of the above "access keys" (Alt+S for file, Enter for folder) still exist in current TB on Windows 7, with the exact behaviour as described above, only that access keys are not *indicated* on the single-file "Save attachment" dialogue unless you press ALT to show them.

Apparently reporter was fine with that "previous" = "current" situation. Beyond that, we probably can't change anything without complex hacking of OS-native dialogues.

So Paul (reporter), in view of my comments above, is it OK for you if we close this bug?
We could also add a comment on respective bugs that if we ever manage to tweak the default native button captions, we should also try adding access keys there.

For that, perhaps Paul or somebody could find the bugs where changes of button captions were requested (e.g. Detach all, Save all attachments vs. Open/Select Folder etc.) and list them here?
Keywords: access
This doesn't look like a Windows native dialog. There's no such thing outside of TB. Also there's no default button on that dialog and no keyboard shortcut to press it. I have pressed Alt and nothing shows. Enter key doesn't work either, it is used to navigate folders in the dialog, not to confirm the selection.
(In reply to Paul-Sebastian Manole from comment #9)
> Created attachment 612820 [details]
> This doesn't look like a Windows native dialog. There's no such thing
> outside of TB.

Paul, thank you for quick followup. Your Screenshot 2 (attachment 612820 [details]) looks *very much* like a Windows native dialogue, and there are *several* such things outside of TB. For illustration, please compare my Screenshot 3 with two native dialogues that ship with windows 7: "New Toolbar" and "Include Folder in Library". Both look exactly like TB's "Save all attachments" dialogue, only that TB tweaks the dialogue icon and title (and *perhaps* the "Select Folder" button caption) before calling the native dialogue (if anybody could point out the TB code where we tweak these, that would be helpful).

> Also there's no default button on that dialog and no keyboard
> shortcut to press it. I have pressed Alt and nothing shows. Enter key
> doesn't work either, it is used to navigate folders in the dialog, not to
> confirm the selection.

I agree with Paul (reporter) that keyboard accessibility is very clumsy in the "Save all attachments" dialogue, so if there's any way we could possibly add Alt+S access key to the "Select Folder" button (this bug), we certainly should.

I didn't point out clearly enough in my comment 6 that Enter will only work to confirm the folder selection if a) focus is not in folder list or on other UI elements that consume Enter for themselves and b) the "Select Folder" button is still selected as "default button". However, that "default button" status easily gets lost when you just use "Tab" to cycle through the dialogue, when unfortunately the "Cancel" button will become default. So Paul is right, there are more cases where "Enter" doesn't work than where it works, which makes it pretty hard to operate that dialogue with keyboard only unless you start typing the name of the target folder and then select from autocomplete.

Magnus, can we CC somebody who knows more about tweaking of native OS dialogues for our purposes? And what's the way forward for this bug?
Attachment #610471 - Attachment description: tb.PNG → Screenshot 1: Missing Access key for "Select Folder" button on "Save all attachments" dialogue (Win 7)
Attachment #612820 - Attachment description: Doesn't seem like a native Windows dialog → Screenshot 2: "Save All Attachments" dialogue (Win7)
Summary: Win7 "Select Folder" button on OS-native "Save All Attachments" dialogue has no access key character (but usually accessible as default button with Enter) → Win7 "Select Folder" button on OS-native "Save All Attachments" dialogue has no access key character (and often inaccessible even with Enter)
(In reply to Thomas D. from comment #10)
> Toolbar" and "Include Folder in Library". Both look exactly like TB's "Save
> all attachments" dialogue, only that TB tweaks the dialogue icon and title
> (and *perhaps* the "Select Folder" button caption) before calling the native
> dialogue (if anybody could point out the TB code where we tweak these, that
> would be helpful).

I don't think we modify the button caption as there are no "Select Folder" string in the source code anywhere where it would do things with the dialog.

> Magnus, can we CC somebody who knows more about tweaking of native OS
> dialogues for our purposes? And what's the way forward for this bug?

Sorry i don't know who that would be, or if the os even lets you do it. 
Technically it may be INVALID, if we can verify it's not technically feasible.
(In reply to Magnus Melin from comment #11)
> (In reply to Thomas D. from comment #10)
> > Toolbar" and "Include Folder in Library". Both look exactly like TB's "Save
> > all attachments" dialogue, only that TB tweaks the dialogue icon and title
> > (and *perhaps* the "Select Folder" button caption) before calling the native
> > dialogue (if anybody could point out the TB code where we tweak these, that
> > would be helpful).
> 
> I don't think we modify the button caption as there are no "Select Folder"
> string in the source code anywhere where it would do things with the dialog.
> 
> > Magnus, can we CC somebody who knows more about tweaking of native OS
> > dialogues for our purposes? And what's the way forward for this bug?
> 
> Sorry i don't know who that would be, or if the os even lets you do it. 
> Technically it may be INVALID, if we can verify it's not technically
> feasible.

I don't think that it's impossible. Just subclass the dialog and modify it. This way or other way, there's no such thing as I impossible to change access keys or button strings. I don't know much Windows programming but I refuse to believe that this request requires a complex hack to fix.

That said, I don't know what more I could say. I'll wait for this to get noticed/fixed/rejected. Either way I'm still going to continue to use TB. I just hope the community doesn't fail to notice legit bug reports. Thank you.
Few things are as such impossible to code, but platform integration suck if you start to do your own implementations of things that are OS territory.
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: