1749998 - Expose browser.download.alwaysOpenPanel in the UI as an "Always open on new downloads" checkbox entry in the downloads button context menu

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, enhancement, P2)

Description

[Katelyn Gadd (:kael)]

Attachment: image.png

As of the last day or two (probably the 97 auto-update?) the downloads panel appears and steals focus any time I download a file. This is a massive usability regression, and I didn't change any settings to cause it to happen. Attached screenshot is what happens after I click download on an attachment in gmail, same for 'save image' in a context menu. I save files a lot and this is approaching 'firefox is unusable for my workflow' levels of annoying.

Comment 1

[Katelyn Gadd (:kael)]

I can get the original behavior by setting 'browser.download.alwaysOpenPanel' to false in about:config. I definitely didn't change this on purpose, all I can think of is autoupdate or somehow this one setting got changed while I was troubleshooting the http3 issue.

Comment 2

[Katelyn Gadd (:kael)]

This appears to be caused by https://bugzilla.mozilla.org/show_bug.cgi?id=1738372, specifically https://searchfox.org/mozilla-central/source/browser/app/profile/firefox.js#534 . Adding a pref for this is nice but it shouldn't change the default behavior to something so disruptive that steals focus.

Comment 3

[Katelyn Gadd (:kael)]

Looking more, apparently 1738372 merely added this pref and the new behavior is part of "download improvements". Thoughts on that:

1. Inflicting this on existing profiles is a mistake. Especially since it seems like getting the old behavior requires you to know about about:config and be able to guess the pref name (this took me multiple tries). I was also unable to find the previous bug about this via search.
2. If you make this default on only for new profiles, that would solve my griping but potentially drives new users away if it breaks common workflows. I'm not aware of any other browser that does this by default, so this makes Firefox inferior for those workflows.
3. If this is driven by user studies/focus tests that show it improves usability for novices, I think you can keep the behavior but need to make fixes to the downloads panel to address it. The simplest fix would be for the panel to not steal focus, but I can imagine there being problems with that (keyboard navigation, for one).
4. If this opening and stealing focus must be kept for Reasons, the downloads panel should (if auto-opened) have a 'don't open this again' checkbox at the bottom that controls the pref, so it's immediately obvious how to make this functionality go away. For users who find it useful, they can just not check that box.
5. EDIT: You could also only do this for downloads that automatically got sent to a folder - when I click 'download' on an attachment in gmail it automatically goes to my downloads folder, so it makes more sense to open the popup. If I right-click save an image and select a location manually via the system save dialog box, it makes no sense to then disrupt me by showing where it went.

Comment 4

[:Gijs (he/him)]

(In reply to Katelyn Gadd (:kael) from comment #3)

Looking more, apparently 1738372 merely added this pref and the new behavior is part of "download improvements". Thoughts on that:

1. Inflicting this on existing profiles is a mistake. Especially since it seems like getting the old behavior requires you to know about about:config and be able to guess the pref name (this took me multiple tries). I was also unable to find the previous bug about this via search.

It's listed in the release notes, which will soon link to this SUMO page (which was published today) - https://support.mozilla.org/en-US/kb/manage-downloads-preferences-using-downloads-menu- . When this change was on nightly, we've communicated publicly about this continuously, both via the draft version of that document which was updated numerous times as we refined the experience ( https://docs.google.com/document/d/1H0Uw7oNgATAN1Ji_MYj7loaY_H-GUmnkNKvwraeHWgQ/edit# ), and the this week in Firefox news. I'm sorry you struggled to find it, and I'm aware that the first week of beta hasn't been brilliant for a number of reasons, and that normally stuff that rides from nightly to beta already has release notes, whereas here we had to re-request them because it'd baked on nightly a while and didn't ride with the first train, plus the SUMO thing took longer to work out than we hoped - and we'll learn from that! - but at this point, I don't think there's much else that we can do about the communications portion here.

(Though I understand that for you, the download panel appearing is the most disrupting part of the overall change to downloads, for other folks some other changes are more disruptive, and trying to explicitly call out each individual change that was part of this project in that release note bullet isn't going to be workable. It'll be better once the link to SUMO is up.)

2. If you make this default on only for new profiles, that would solve my griping but potentially drives new users away if it breaks common workflows. I'm not aware of any other browser that does this by default, so this makes Firefox inferior for those workflows.

Every browser opens downloads UI when you download something, so I don't understand this comment. Before this change, Firefox would have opened the "what do you want to do with this file" dialog, which also stole focus.

5. EDIT: You could also only do this for downloads that automatically got sent to a folder - when I click 'download' on an attachment in gmail it automatically goes to my downloads folder, so it makes more sense to open the popup. If I right-click save an image and select a location manually via the system save dialog box, it makes no sense to then disrupt me by showing where it went.

I'm happy to morph this bug into a request to just not show the panel if saving images/media (and maybe webpages? Less clear to me if that needs the same treatment) as an explicit user action, though I'm not sure how easy it would be to address because of the disconnect between what initiates the download and the opening of the download panel (which is event driven, ie happens when creating a new download, irrespective of its source). Would that be a fair representation of what you're concerned about here?

I'll add that I'm sort of confused that making it easier to open the resulting local file is a net negative for the image/media saving usecase (and one which AFAICT hasn't come up at all, as a specific point, during 2 months of testing on nightly!), so I would be interested to hear more context around that.

Comment 5

[Katelyn Gadd (:kael)]

If I go to the Firefox website in Edge and click Download, it automatically starts downloading to my Downloads folder. A little flyout does appear to show me that it was downloaded, but the flyout is small and does not steal focus.
In chrome back when downloads still appeared in a bar at the bottom (maybe they still do, I don't have it installed), that was entirely non-disruptive - a download would start and the icon would appear there and hang around until you dealt with it, if ever.

"Every browser opens downloads UI when you download something, so I don't understand this comment. Before this change, Firefox would have opened the "what do you want to do with this file" dialog, which also stole focus." Yes, but this new downloads popup steals focus even if I just finished with the save dialog. I already confirmed what I wanted it to do and where the file should go. In the past, Firefox would show me a little indicator via the downloads button and I could click that to find my newly downloaded file. I think it's reasonable to want to go beyond this, it's just really unfortunate if it has to occur in a way that disrupts interaction.

Making it easier to open the file is totally fine, so if the downloads popup can be made non-disruptive I think that's enough to consider this not a problem anymore. Alternately, as I suggested you could perhaps just make it really easy to turn this behavior off. Having it in the release notes will help, but for many people a behavior like this feels random and not associated with an update so they may not think to check release notes.

Comment 6

[:Gijs (he/him)]

(In reply to Katelyn Gadd (:kael) from comment #5)

If I go to the Firefox website in Edge and click Download, it automatically starts downloading to my Downloads folder. A little flyout does appear to show me that it was downloaded, but the flyout is small and does not steal focus.

Without stealing focus, the change is not keyboard accessible, and also not noticeable for users of assistive technology without further work (ie a blind user would not realize anything had downloaded). So there's a reason we steal focus.

"Every browser opens downloads UI when you download something, so I don't understand this comment. Before this change, Firefox would have opened the "what do you want to do with this file" dialog, which also stole focus." Yes, but this new downloads popup steals focus even if I just finished with the save dialog.

So this goes back to wanting to specialcase situations where explicit browser-chrome level actions (usually from the menu, context menu, or shortcut) are what leads to the download, right? Can you elaborate on why, in this case, the focus stealing is disruptive? I would not have expected that if you were using the context menu, focus would be in a "useful" place anyway (ie if I focus an inputfield, then context-click an image, and click 'save as', focus does not return to the image, irrespective of whether the downloads panel opens). And additionally, can you perhaps provide some context around the workflow in which you encounter this scenario? What are you trying to do, and how does the downloads panel get in the way of that? I'm sorry because I realize this is likely obvious to you, but it's not to me, and getting more of an idea of what the context is might help in figuring out what else we can do to help.

Having it in the release notes will help, but for many people a behavior like this feels random and not associated with an update so they may not think to check release notes.

I should hope that this is less so on release, where an update happens once a month, and is more clearly an 'event' as opposed to on beta where they happen every other day or so... Certainly, I see more bugreports (in general, not related to this) where people mis-attribute to a given Firefox release update, than where something turns out to be a regression and they didn't realize...

But really, there is a difficult trade-off here, because of course we have no idea, for individual users, who this behaviour is likely to annoy or surprise, and who couldn't care less. Based on our data, where we've had a significant uptick of the ratio of files opened vs downloaded, we think the new flow helps people.

Comment 7

[Katelyn Gadd (:kael)]

(In reply to :Gijs (he/him) from comment #6)

(In reply to Katelyn Gadd (:kael) from comment #5)

If I go to the Firefox website in Edge and click Download, it automatically starts downloading to my Downloads folder. A little flyout does appear to show me that it was downloaded, but the flyout is small and does not steal focus.

Without stealing focus, the change is not keyboard accessible, and also not noticeable for users of assistive technology without further work (ie a blind user would not realize anything had downloaded). So there's a reason we steal focus.

This is only relevant for the case where a download occurs without the user requesting it, right? I agree that it is valuable for that scenario - I don't know how common it is in the wild since for me Firefox almost always prompts or opens a save dialog.

"Every browser opens downloads UI when you download something, so I don't understand this comment. Before this change, Firefox would have opened the "what do you want to do with this file" dialog, which also stole focus." Yes, but this new downloads popup steals focus even if I just finished with the save dialog.

So this goes back to wanting to specialcase situations where explicit browser-chrome level actions (usually from the menu, context menu, or shortcut) are what leads to the download, right? Can you elaborate on why, in this case, the focus stealing is disruptive? I would not have expected that if you were using the context menu, focus would be in a "useful" place anyway (ie if I focus an inputfield, then context-click an image, and click 'save as', focus does not return to the image, irrespective of whether the downloads panel opens). And additionally, can you perhaps provide some context around the workflow in which you encounter this scenario? What are you trying to do, and how does the downloads panel get in the way of that? I'm sorry because I realize this is likely obvious to you, but it's not to me, and getting more of an idea of what the context is might help in figuring out what else we can do to help.

It's an extra interaction to dismiss the popup that doesn't communicate additional info to the browser, since user already intentionally confirmed the download + its target location by interacting with the system 'save file' dialog box. It would also kind of make sense to bypass this if I just dealt with the Firefox 'what should I do with this file' modal, since that also asks where to put it, but in that case I can understand wanting to open the flyout so that it's easy to navigate to the place where FF put it, since your default Downloads folder might be in a weird spot.

I actually misunderstood the way this focus-stealing popup behaves, because it appears to only partially steal focus - Ctrl+F4 will still close the current tab despite the tab no longer having focus, and that was the main flow I was concerned about here. The popout does block mouse input going to the tab, but it's at least not a very big popout so that is a less general concern on big monitors - while it's 25% of my vertical real estate, it's not very wide so it only works out to like 5% of my total desktop real estate (I don't know what it's like on a consumer 1080p monitor though - hopefully not too bad?)

It's possible the resolution to this is that websites that require this sort of interaction will be redesigned to cope with the way things behave now, especially if Chrome migrates to this model. "Open a bunch of tabs to save that the end user then has to close" was already bad and this makes it slightly worse, so ideally websites will stop doing it. It's already the case that some websites address this by just generating zip files containing all the downloads, and then it's the end user's responsibility to use an external tool to unpack them, which solves the problem of the browser having to make the downloads flow smooth.

I should note that if I'm trying to use the keyboard to download multiple attachments in gmail, this still regresses that flow - while ctrl-f4 to close tabs still works with the popout open, it fully stops me from navigating in the gmail tab after I've used the keyboard to kick off a download - I have to find my way out of the popup. Thankfully that is one consistent key, and I imagine not too many people use the browser this way so maybe it's not a big deal? If the popup only intercepted specific keys that would also fix this, it eats arrow keys to allow me to select older downloads and it has multiple focus targets that eat tab. If the goal is to enable accessible keyboard navigation one alternate solution that doesn't disrupt navigation would be a dedicated 'open my last download' hotkey that's always available and has an associated visual element - maybe the downloads flyout becomes smaller and less disruptive in that circumstance.

At this point though that's just speculative design. Ctrl+F4 still working means that my common workflows here will still work, they just behave strangely now - I was confused enough by the new behavior that I didn't fully explore how it interacted with hotkeys.

Having it in the release notes will help, but for many people a behavior like this feels random and not associated with an update so they may not think to check release notes.

I should hope that this is less so on release, where an update happens once a month, and is more clearly an 'event' as opposed to on beta where they happen every other day or so... Certainly, I see more bugreports (in general, not related to this) where people mis-attribute to a given Firefox release update, than where something turns out to be a regression and they didn't realize...

But really, there is a difficult trade-off here, because of course we have no idea, for individual users, who this behaviour is likely to annoy or surprise, and who couldn't care less. Based on our data, where we've had a significant uptick of the ratio of files opened vs downloaded, we think the new flow helps people.

It's good to hear that this new flow is supported by metrics, I was hoping it would be. For me the ideal resolution would just be a 'don't show this again' checkbox that appears for any existing users this behavior is pushed onto, because then you don't have to make any additional changes anywhere else and users don't have to dig into about:config (something the firefox UI design team rightfully seems to wish to discourage). I can imagine less advanced users clicking that checkbox without realizing it'll actually make their experience worse, though...

Comment 8

[Marco Bonardo [:mak]]

I wonder if you could move focus to content using F6, but I admit I don't fully understand your workflow.

It's also possible that the fact this panel appears on top of other things, partially stealing focus, makes the user think it must be dismissed, when in most cases you can continue as usual. That would be more a perception issue, than a technical one.
I'm not sure what we can do here, apart annotating your feedback and keep brainstorming about future improvements, it doesn't sound like the new behavior is disrupting for your workflow, but mostly different and requiring some time to digest.
Which change would you think would improve your workflow while preserving the current behavior?

Comment 9

[Katelyn Gadd (:kael)]

To be clear and avoid wasting more of your time: My common workflows here actually work fine with this change, I just didn't understand the exact focus/input behavior of the popup and was confused by that perception issue you mentioned - it was so jarring that I immediately went searching for a pref instead of experimenting with it. New users won't have that problem. I can definitely imagine the team finding ways to improve on this stuff in the future. The keyboard navigation thing was just me testing that flow out since accessibility was mentioned - the two workflows for me (use mouse to save+close, use keyboard to save+close) do still work as-is since I can use the Close Tab keyboard hotkey to close the tab and automatically dismiss the popup.

Off the top of my head I think the simplest "solution" for users like me would just be a "don't show this again" checkbox that appears if you were opted into this new behavior. You could probably flush this to the right in the empty space next to 'show all downloads'. For me of course the about:config pref is sufficient, so I don't need that checkbox - it's just how I would try to address the confusion of existing FF users when this hits stable.
A more elaborate/problematic alternative would be for the automatic popup to be smaller (only show 1-2 downloads instead of the 5 + show all button it is now), because making it smaller would probably be less visually disruptive and distracting.

Comment 10

[:Gijs (he/him)]

(In reply to Katelyn Gadd (:kael) from comment #9)

Off the top of my head I think the simplest "solution" for users like me would just be a "don't show this again" checkbox that appears if you were opted into this new behavior. You could probably flush this to the right in the empty space next to 'show all downloads'. For me of course the about:config pref is sufficient, so I don't need that checkbox - it's just how I would try to address the confusion of existing FF users when this hits stable.

We've been very reluctant to do this because a recurring issue with downloads (and part of the motivation for these changes in the first place) is that we know people struggle to find downloads (bugs I found quickly are bug 1646450, bug 1538305, but I'm sure there have been more of these...). We have data backing this up as well: among other things, on beta right now, the rate of people opening their downloads is up very significantly compared to 96. We think this is a (fixed) discoverability issue.

Making it easy to not show the panel, and especially now that we don't first show an entire dialog asking users whether they want to open/save files, will likely cause a number of people to (reflexively) tick the box ("get rid of this thing which just showed up when I didn't expect it"), which would then make the discoverability/usability problem worse, because then they have neither the old dialog nor the new panel alerting them that a download happened.

Unfortunately, although adding a checkbox in the location you suggested might work in English, in most other locales the two things won't fit on one line, so then we'd have to increase the size of the panel even further to accommodate a permanent toggle, which would then forever take up space but users are unlikely to use more than once...

I think I could buy creating a context menu checkbox option for this in the downloads panel, I guess? Marco, how does that sound?

A more elaborate/problematic alternative would be for the automatic popup to be smaller (only show 1-2 downloads instead of the 5 + show all button it is now), because making it smaller would probably be less visually disruptive and distracting.

Yeah, I can see the argument for this, and I can also see some other people will be unhappy about that trade-off. :-(
"Make it a pref" is the obvious "get out" clause there, but that would introduce another maintenance burden, and it's unclear if people would figure out the pref existed and so the benefits will likely be limited anyway.
We could try to make the entries less tall by shaving spacing off, but I don't know how realistic that is, without losing information (which will likely annoy some other, third set of people) or making things look squished (hello, fourth set of people who we could annoy).

Apropos, I'll add that I really appreciate your willingness to explain your usecases and discuss a way forward here. :-)

Comment 11

[Marco Bonardo [:mak]]

(In reply to :Gijs (he/him) from comment #10)

I think I could buy creating a context menu checkbox option for this in the downloads panel, I guess? Marco, how does that sound?

I suspect we could find a compromise like "Show this panel every time" or "Show for new downloads", rather than "Show this panel for every new download" to make a checkbox fit. The panel for me is already very large and I don't see why it would be an issue...
BUT, in general I'm not a big fan of "don't show this thing again" options because that is usually a pointer that your UI is percepted as obtrusive. Also if the option is very visible users tend to disable it pretty soon, without enough testing whether it's effectively useful or not.
Finding a better solution to the obtrusive perception problem would be my best wish but... I also understand it's not a trivial UX problem to solve (I similarly don't like the Chrome solution, for example).

While I'd expect the context menu for this panel to be mostly download-related.... there is already a Clear Preview Panel option that is global.
So, I agree that we could add an option to the context menu, but I think we should also add a separator above Clear Preview Panel and this new option, to separate them from single-download related options above.

A more elaborate/problematic alternative would be for the automatic popup to be smaller (only show 1-2 downloads instead of the 5 + show all button it is now), because making it smaller would probably be less visually disruptive and distracting.

Yeah, I can see the argument for this, and I can also see some other people will be unhappy about that trade-off. :-(

The panel is very large for me, shaving some padding may help overall, even if I doubt it will solve the perception problem.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 13

[Marco Bonardo [:mak]]

Let's call this an enhancement to expose the option in the panel context menu.
Gijs should this block some tracking bug for downloads work follow-ups?

Comment 17

[rsbrux]

To supplement Katelyn's comments: I do not follow the nightly builds or read the new release notes when installing an update. I found the new popup intrusive and counterproductive. I have found out how to disable it, but suggest that in future such new features be disabled by default in exiting profiles. Those who are interested in the new features can enable them, but the new features should not be forced on existing users.

Comment 21

[Michael Dell]

I hate to say this, but as a less than tech savvy user who doesn't deal with the about:config if he has to, what actually has been the resolution.

The panel is disconcerting and if I have a number of quick downloads blocks a 3rd of my screen.

Comment 22

[Jim DeLaHunt]

Hello, I just arrived at this bug report because I, like :kael, had my workflow disrupted enough by the Downloads Panel opening that I searched for ways to stop it. That led me to a Mozilla Support answer about changing the browser.download.alwaysOpenPanel config to False, and to this bug report. Early in my use of Firefox 98 I was inconvenienced by Firefox ceasing to ask me where to store files, so I had to fumble my way to changing the setting back to where Firefox asks me where to store files.

I would like to tell :Gijs about my use case.

(In reply to :Gijs (he/him) from comment #6)

(In reply to Katelyn Gadd (:kael) from comment #5)

If I go to the Firefox website in Edge and click Download, it automatically starts downloading to my Downloads folder. A little flyout does appear to show me that it was downloaded, but the flyout is small and does not steal focus.

Without stealing focus, the change is not keyboard accessible, and also not noticeable for users of assistive technology without further work (ie a blind user would not realize anything had downloaded). So there's a reason we steal focus.

"Every browser opens downloads UI when you download something, so I don't understand this comment. Before this change, Firefox would have opened the "what do you want to do with this file" dialog, which also stole focus." Yes, but this new downloads popup steals focus even if I just finished with the save dialog.

So this goes back to wanting to specialcase situations where explicit browser-chrome level actions (usually from the menu, context menu, or shortcut) are what leads to the download, right? Can you elaborate on why, in this case, the focus stealing is disruptive? I would not have expected that if you were using the context menu, focus would be in a "useful" place anyway (ie if I focus an inputfield, then context-click an image, and click 'save as', focus does not return to the image, irrespective of whether the downloads panel opens). And additionally, can you perhaps provide some context around the workflow in which you encounter this scenario? What are you trying to do, and how does the downloads panel get in the way of that? I'm sorry because I realize this is likely obvious to you, but it's not to me, and getting more of an idea of what the context is might help in figuring out what else we can do to help.

Having it in the release notes will help, but for many people a behavior like this feels random and not associated with an update so they may not think to check release notes.

I should hope that this is less so on release, where an update happens once a month, and is more clearly an 'event' as opposed to on beta where they happen every other day or so... Certainly, I see more bugreports (in general, not related to this) where people mis-attribute to a given Firefox release update, than where something turns out to be a regression and they didn't realize...

But really, there is a difficult trade-off here, because of course we have no idea, for individual users, who this behaviour is likely to annoy or surprise, and who couldn't care less. Based on our data, where we've had a significant uptick of the ratio of files opened vs downloaded, we think the new flow helps people.

I frequently download files because I want to store my own copy of a file in my document archives for future reference. I typically do not want to open the file immediately.

The workflow is: I am viewing a web page in Firefox. The page has a link to the file a want to store. I right-click and say "Download link as…". Firefox pops up a dialogue asking me where I want to save the file. I go through a standard File Save dialogue to put the file where I want it. I look at that web page, or at another window, to continue my task. Then Firefox pops up this Download Panel. At the very least it distracts me from my task. It also obscures part of the web page, which may or may not matter. I have to interrupt my task to click the Download Status icon, to make the panel go away.

The panel adds little value in helping me discover the files, because I know where they are; I have just explicitly told Firefox where to store them. The panel adds little value in easily opening the files, because I don't want to open the files right away.

A concrete example from just now. I am logged in to my credit card company's website. I am downloading this month's statement and transaction data.

• There is a link for the statement, as a PDF file. I click the link. Firefox asks me where to save the statement. I tell it.
  • Firefox pops up a distracting download panel. I dismiss it.
• There is a link for the transaction data as a CSV file. I click the link. Firefox asks me where to save the statement. I tell it.
  • Firefox pops up a distracting download panel. I dismiss it.
• There is a link for the transaction data as a OFX file. I click the link. Firefox asks me where to save the statement. I tell it.
  • Firefox pops up a distracting download panel. I dismiss it.
• I turn to my bookkeeping program and reconcile my books with the credit card company's transaction list (under the download panel).

I hope this makes my use case clearer. I realise there are many use cases. For others, the download panel's spontaneous appearance is a blessing. (I do informal family IT support :-) for some of them!) But for me, I want the distraction to stop.

Comment 23

[Jim DeLaHunt]

(In reply to :Gijs (he/him) from comment #10)

We've been very reluctant to do this because a recurring issue with downloads (and part of the motivation for these changes in the first place) is that we know people struggle to find downloads (bugs I found quickly are bug 1646450, bug 1538305, but I'm sure there have been more of these...). We have data backing this up as well: among other things, on beta right now, the rate of people opening their downloads is up very significantly compared to 96. We think this is a (fixed) discoverability issue.

Let me point out that interpreting this metric — rate of people opening their downloads — as "higher is better" contains an assumption: that people want to immediately open the files they download. This assumption does not apply for my use case, as I explained in comment 22. My successful usage would result in this metric being low.

However, I applaud the data-driven approach to design which this metric reveals!

Comment 24

[support]

(In reply to Jim DeLaHunt from comment #23)
My successful usage would result in this metric being low.

However, I applaud the data-driven approach to design which this metric reveals!

As these metrics are biased by people giving away their data, people who do not share their data, will be underrepresented in it, but may be still the major userbase due to ever growing privacy concerns. So is automatic data alone a good base for these kind of decisions? I do not think so. ATM it may be the only source, but that can be changed in a way more people participate, because it's privacy protected.

Short form:

• Extra tool to handle it in autostart
• pops up if a new survey is required
• random uuid per survey
• tool ensures result uniqueness per survey
• once per new major release cycle, a survey for x releases ahead is started
  this way ..
• it's result is back in time
• not to frequent to be annoying
• does not annoy in the update process
• and, most import, as it's active data, really representing what people think about it.

Comment 27

[Peter Urbanec]

My typical workflow is:

1. Select a file to download
2. Use the file requester to provide download location and file name
3. Select Save
4. Download panel appears

I have Firefox configured to ask me where to download each item because I want to download files into their correct final destinations, rather than dumping everything into a Downloads folder.

The appearance of the download panel seems superfluous given the above sequence of events. It would make more sense to not open the downloads panel if the download was added as a result of the user already specifying the download location. If the user has selected where to save the file, there is no need to open the download panel and to create an additional distraction. By all means, add an entry to the panel, but keep the previous behaviour of leaving the panel closed and animating the icon to indicate the progress of the download if the user specified where to save the file.

Comment 28

[Marco Bonardo [:mak]]

Gijs I think what was agreed upon was to use the downloads button context menu (the one that contains auto hide), rather than the panel context menu. Did I understand correctly? If so it may be worth updating the title to avoid confusion.

Comment 29

[Rocky]

Checkboxes allow the user to select one or more options from a set. Typically, you should present each checkbox option in a vertical list.

To create each checkbox option, create a CheckBox in your layout. Because a set of checkbox options allows the user to select multiple items, each checkbox is managed separately and you must register a click listener for each one.

A key class is the following:
Responding to Click Events
https://bestbuysteamcleaners.com/
When the user selects a checkbox, the CheckBox object receives an on-click event.

To define the click event handler for a checkbox, add the android:onClick attribute to the <CheckBox> element in your XML layout. The value for this attribute must be the name of the method you want to call in response to a click event. The Activity hosting the layout must then implement the corresponding method.

For example, here are a couple CheckBox objects in a list:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
<CheckBox android:id="@+id/checkbox_meat"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@string/meat"
android:onClick="onCheckboxClicked"/>
<CheckBox android:id="@+id/checkbox_cheese"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@string/cheese"
android:onClick="onCheckboxClicked"/>
</LinearLayout>

Comment 32

[Karl]

I find the current (FF99.0) behaviour annoying too.
I have "ask me" set for PDF. I click on a pdf, answer the choice with "save", choose/confirm the location where I want to file that PDF, and continue browsing in the page the pdf was linked from. In browsing, I use cursor-up and cursor-down keys for scrolling through the content. All of a sudden (when the download completes) the downloads list pops up and my cursor keys no longer scroll the page I am viewing but instead move the blue frame between download items, and that interaction locks the download panel and makes it stay there instead of disappearing quickly. I have to move my hand to the mouse to regain control. Alternatively as soon as the download panel appears, I have to leave my hands off the keyboard for several seconds until it disappears, this stalls me from continuing to do what I want to do. No thanks, I didn't ask for that disruption.

If I choose open at the prompt, the associated application will open, I also don't need the additional flicker of the download list, I need not interact with it, what I want to happen will already happen without additional action by me. (in that case, the appearance is so brief, and the viewer will grab focus almost immediately afterwards, that focus is not an issue, it is only visually distracting)

Comment 33

[Karl]

(I thought the download panel disappears if I do nothing but apparently not, I have to take the mouse and click elsewhere, it seems. apologies for any confusion resulting from my wrong perception.)
what also confuses me: while the download panel is present, the mouse cursor does not change shape as expected. Without the download panel, moving the mouse over a link will switch from arrow pointer to hand, while the download panel is present the cursor remains pointed arrow when hovering over a link. Clicking still does the same thing but the fact that the cursor does not change shape would suggest to me that it may not. I am puzzled why it modifies this aspect.

Comment 34

[Shane Hughes [:aminomancer]]

Attachment: Bug 1749998 - Expose alwaysOpenPanel in context menu. r=mak,Gijs

This patch adds a new menuitem to the toolbar context menu that
functions analogously to the downloads button auto-hide menuitem.
It's visible when the context menu is opened on the downloads button,
and hidden otherwise. It toggles browser.download.alwaysOpenPanel.
Also add some tests to make sure it's showing in the correct conditions
and having the correct effect in practice. While we're at it, make some
slight simplifications of related tests.

Comment 35

[Shane Hughes [:aminomancer]]

FYI I tentatively changed the menuitem string to "Show Panel When Starting Downloads" — if anyone disagrees or has another idea, let me know 😊

Comment 36

[Romain Testard [:RT]]

Meridel, can you please help us get a review to approve the string?

Comment 37

[Meridel [:meridel]]

Hm, I don't think that is the right place for the new menu item. All the items in that first section are referring to the download panel menu button, not the panel.

Gijs, I know moving things around gets tricky. See below... possible to add another separator?

Pin to overflow menu
Hide button when empty
Remove from toolbar
----------------------- 
Show panel when download begins  
----------------------- 
Bookmarks toolbar >
-----------------------
Customize toolbar...

Note: string does not change with state change. We are using the checkmark pattern to communicate state.

Comment 38

[Meridel [:meridel]]

Gijs agrees with the above proposal. Flod, we are adding a new string to the context menu on the download menu button. Do you have any concerns with this string? It will use a checkmark to indicate state change:

Show panel when download begins

Comment 39

[Francesco Lodolo [:flod]]

(In reply to Meridel [:meridel] from comment #38)

Show panel when download begins

No issue on my side, it's clearer and shorter than what I proposed.

Comment 40

[Meridel [:meridel]]

Michael, this is just an FYI about a new string in product. I do not think there are any privacy or security considerations.

Summary: The downloads panel opens automatically from the toolbar when you start a download. Some users do not want it to open automatically so we are adding a new string to the context menu so users can choose to show or not show the panel.

String:
Show panel when download begins

Note: the user can check and uncheck to control the behavior.

Comment 41

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cf50b25d52a0
Expose alwaysOpenPanel in context menu. r=mak,Gijs,fluent-reviewers,flod

Comment 42

[Sandor Molnar[:smolnar]]

Backed out changeset cf50b25d52a0 (bug 1749998) for causing browser-chrome failures in browser_downloads_panel_opens.

Backout link: https://hg.mozilla.org/integration/autoland/rev/95d532a6b1d5b9d262bb3865a0fffb32924f7360

Push with failures

Failure log

INFO - TEST-UNEXPECTED-FAIL | browser/components/downloads/test/browser/browser_downloads_panel_opens.js | Always Open is enabled. - Got "", expected "true"

Comment 43

[Shane Hughes [:aminomancer]]

Thanks, it looks like we miscalculated about using toggleAttribute, it actually needs checked="true" not just checked=""

Comment 44

[Karl]

(In reply to Meridel [:meridel] from comment #38 and previous ones)

Show panel when download begins

shouldn't this be "Show panel when download completes"? I was under the impression that the panel is shown at that point in time, not when the download begins (which is already happening during the always ask prompt, in my case)?

Comment 45

[Shane Hughes [:aminomancer]]

(In reply to Karl from comment #44)

shouldn't this be "Show panel when download completes"? I was under the impression that the panel is shown at that point in time, not when the download begins (which is already happening during the always ask prompt, in my case)?

No, the panel is shown on start. If the always ask prompt is enabled, then (currently) the panel will open after the dialog has been accepted. That is technically after data has been written to disk but still at the time of this start notification. And if the file is small, then the download will finish as soon as it starts, making it look like the panel opens on finish. You can see it more easily with a bigger download.

But this won't matter once bug 1739348 ships — the downloads panel will not be opened at all if the download that would have opened it already launched a dialog. So that would basically mean no panel if the content type was set to "always ask" or if it was set to "save" and you had "always ask where to save files" enabled. The panel would only show if it's going to be the first indication of a download proceeding. So in your case, if you have "always ask" set for all types, you won't see a panel at all, irrespective of how you set the alwaysOpenPanel pref.

Comment 46

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d65e39e82568
Expose alwaysOpenPanel in context menu. r=mak,Gijs,fluent-reviewers,flod

Comment 47

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/d65e39e82568

Comment 48

[Michael Feldman (use NI)]

thumbs up emoji
Just clearing NI

Comment 49

[Ardelean Oana, Desktop QA [:oardelean]]

Hello,

I managed to reproduce the issue on Firefox 101.0(20220526203855) on Windows 10 x64. I can confirm that the Show Panel When Download Begins is present as an option in the Downloads context menu on both Firefox 102.0b8(20220614185842) and Nightly 103.0a1(20220614213729) on Windows 10 x64, Ubuntu 22.04 and macOS 11. While Firefox 102.0b8 respects the user's selection (Downloads Panel is shown when the preference is on, hidden when off), Nightly 103.0a1 will not display the Downloads Panel even if the option is selected. Should I file a separate bug for this issue?

Thank you.

Comment 50

[:Gijs (he/him)]

(In reply to Ardelean Oana from comment #49)

Nightly 103.0a1 will not display the Downloads Panel even if the option is selected. Should I file a separate bug for this issue?

Will not display it when? How are you starting the download?

Comment 51

[:Gijs (he/him)]

(I expect you're seeing the fix for bug 1761265)

Comment 52

[Shane Hughes [:aminomancer]]

(In reply to Ardelean Oana from comment #49)

I managed to reproduce the issue on Firefox 101.0(20220526203855) on Windows 10 x64. I can confirm that the Show Panel When Download Begins is present as an option in the Downloads context menu on both Firefox 102.0b8(20220614185842) and Nightly 103.0a1(20220614213729) on Windows 10 x64, Ubuntu 22.04 and macOS 11. While Firefox 102.0b8 respects the user's selection (Downloads Panel is shown when the preference is on, hidden when off), Nightly 103.0a1 will not display the Downloads Panel even if the option is selected.

Thanks for the feedback. This patch just adds a menuitem for setting a pref browser.download.alwaysOpenPanel, but doesn't change the behavior of the pref. The behavior when originally added used to apply in more contexts than it does currently, because this auto-opening behavior is now a boolean property of each download object, so it can be set differently depending on how the download is created. And several folks are working on setting that value differently in different contexts (see bug 1761265, bug 1762033, bug 1739348, possibly more in the future).

Should I file a separate bug for this issue?

If you check those bugs linked above and you think it's consistently failing to display the panel in a situation not listed in any of those bugs, then yeah that can be a new bug in the Firefox::Downloads Panel component.

Comment 53

[Ardelean Oana, Desktop QA [:oardelean]]

Hello,

Initially I tested on Nightly and downloaded via context menu(for images) and also a PDF for a test sample.
Re-tested again with another type of test file and it seems that the bug you mentioned is indeed what I encountered (bug 1761265).
I assume I can mark this as verified since the new Show panel when download begins option in the Downloads context menu is implemented and working?

Thank you.

Comment 54

[:Gijs (he/him)]

(In reply to Ardelean Oana from comment #53)

I assume I can mark this as verified since the new Show panel when download begins option in the Downloads context menu is implemented and working?

Yes please!

Comment 55

[Ardelean Oana, Desktop QA [:oardelean]]

Thank you! Updating now.