Closed Bug 314893 Opened 19 years ago Closed 17 years ago

Downloads complete popup steals focus from active text entry boxes

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.9beta2

People

(Reporter: xs, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files, 3 obsolete files)

hacky workaround for focus (set focus when window gets focus)
1.58 KB, patch
Details | Diff | Splinter Review
Fix.patch(Now no tabs)
4.69 KB, patch
Gavin
: review-
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8) Gecko/20051025 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

To reproduce, start downloading something around 2-3Mbs and while it's downloading, type some text into a text entry box - e.g. URL entry box or google search box. When the download finishes and popup "Downloads complete" appears, the focus is switched to the popup and never returns to text entry box.


Reproducible: Always

Steps to Reproduce:



Expected Results:  
I don't think the focus should be ever given to "downloads complete" window at all.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051102 Firefox/1.5 ID:2005110218
I see the same.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051102 Firefox/1.6a1

Ria, do you think you could get a regression range on this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows Server 2003 → All
Hardware: PC → All
Version: unspecified → Trunk
Flags: blocking1.8rc2?
Jesse, can you provide a more detailed explanation about why you nominated this as a stop ship bug? It helps us evaluate the bug if we understand why it was nominated. Thanks!
I want to know whether this bug is a recent regression and how many users it affects.  It sounds a lot like bug 312227...
I've only got this problem if I set the download-manager to open when a download starts. Otherwise the focus stays where it is, indifferent, wheter I'm typing the moment the download finishes or not.

Focus is also gone if I set the download-manager to close when the download is finished.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051103 Firefox/1.5 ID:2005110303
It is a regression:
1.9a1_2005090206 - 1.9a1_2005090222
1.8b4_2005090605 - 1.8b4_2005090613
Ria, that sounds like the regression range for bug 312227, which was fixed on the branch around October 24.  Did that fix ever work for you?
(In reply to comment #7)
> Ria, that sounds like the regression range for bug 312227, which was fixed on
> the branch around October 24.  Did that fix ever work for you?
>

I see it also in a build of October 26.
Re-checked, and both regression ranges are right.
Keywords: regression
Tested it on a brand-new profile with default settings (first run).
going to test this on a clean tree, but seems to work ok
Seems like a low-impact issue that will not block rc2.
Flags: blocking1.8rc2? → blocking1.8rc2-
*** Bug 315919 has been marked as a duplicate of this bug. ***
It's pretty annoying bug. Definately should be a blocker!
Agreed. It's still in RC3:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Happened while I was downloading several files and was typing an entry in a PHPBB forum. It's especially annoying when you happen to hit backspace and it kicks you one step back in the history.

Testet this with a regular form a(damn there it was again while typing this - this time it activated find-as-you-type).. as well.

Please don't release Firefox with this bug, it's nerve wrecking.
This is a very annoying regression, especially if you're blogging at the time.  The "downloads complete" popup is cue enough that the file is done downloading; the behavior needs changed back to how it was.  FF should display the popup but not steal focus, ever.

If you release the next version of FF with this behavior, I predict you will have a mob of angry snarky bloggers talking about it.
This is a "regression" from bug 309027. I haven't debugged it fully, but I believe the problem is that since we used to stick the old focus controller in a suppressed state, we ended up ignoring the blur event set at the input. Since we now properly unsuppress the focus controller, we respect the blur and the focus gets stolen.

I'm going to nominate this for blocking the next Firefox release. In the meantime, we should try to drive this hack into the trunk, and I'll see if I can investigate a better solution.
Blocks: 309027
Flags: blocking1.8.0.1?
Not blocking. A reviewed, trunk-tested patch might get approval but time is short for 1.8.0.1 and there are much more critical bugs.
Flags: blocking1.8.0.1? → blocking1.8.0.1-
*** Bug 337591 has been marked as a duplicate of this bug. ***
Focus is also stolen from other applications. See Bug 337591 (duped to this) for a description of that.
I'm using the latest nightly: Gecko/20060623 Minefield/3.0a1.

When a download completes the focus is also stolen from the URL edit.
It does not matter if the download manager is open, closed, or whatever.
My settings are set to not open the download manager at all.

The focus is stolen every time a download completes. 
Fix this already. This bug has been open for over 6 months; it's an extremely visible and annoying bug that makes firefox look totally unprofessional. This should block the next release.
Flags: blocking-firefox2?
Too late to play around with focus.

Mats, a trunk patch sooner rather than later would be great.
Flags: blocking1.9?
Flags: blocking-firefox2?
Flags: blocking-firefox2-
*** Bug 353809 has been marked as a duplicate of this bug. ***
Any update? Has this been fixed in the RCs?
*** Bug 358048 has been marked as a duplicate of this bug. ***
*** Bug 360655 has been marked as a duplicate of this bug. ***
Flags: blocking-firefox3+
*** Bug 364825 has been marked as a duplicate of this bug. ***
The downloads completed notification appears to steal the focus and is shown on
top of certain game windows.

Could you please use the native Windows balloons, that do not have these
issues?
Olaf is correct, that the funky slide-up "Downloads Complete" notification is the cause of the focus-stealing behaviour.  This has been occurring/annoying the hell out of me since the days of 0.5, and continues still in both 1.5.x and 2.0.x.

I don't necessarily advocate the use of native Windows balloons, because I'm not sure that's necessary.  The moz dev's would know better though.  This is probably the only primary annoyance for me.
(In reply to comment #28)

> Could you please use the native Windows balloons, that do not have these
> issues?

Happens on OS X as well, and with text boxes within pages (eg google mail chat).
Target Milestone: --- → Firefox 3 beta1
I have the same problem - or rather had it for ages - and I have the pop-up notification disabled. This is on up-to-date 2.0.*

Was there any progress in 3.x made on this bug?

P.S. option to disable the pop-up notification is needed: Ff often breaks full screen/direct x applications by messing up screen with the /smoothly/ (frankly: ugly) thing poping out. Which has something to click, but by the time you reach it with mouse cursor - it already starts closing itself. Ugly.
Target Milestone: Firefox 3 M7 → Firefox 3 M9
Target Milestone: Firefox 3 M9 → Firefox 3 M10
(In reply to comment #10)
>  but seems to work ok


Hi Mike ,
I applied the patch on Firefox 2.0.0.6 source code. and built it..
But the problem remains there...
Download manager alert still takes away the focus..
Can you please explain how it worked for you ?



(In reply to comment #35)
> Can you please explain how it worked for you ?
It isn't an acceptable fix, so I wouldn't suggest using it anyway.
Flags: blocking1.8rc2-
Flags: blocking1.8.0.1-
Flags: blocking-firefox2-
I am trying to fix this bug..
Can anyone answer these questions ?
Why are there two implmentation of nsIDownloadManager ?
one is in mozilla\toolkit\components\downloads\
and other one is in mozilla\xpfe\components\download-manager

Which implementaion is used by download.js in mozilla\toolkit\mozapps\downloads\content
when it instantiates download-manager using
<<JS code start>>
const dlmgrContractID = "@mozilla.org/download-manager;1";
const dlmgrIID = Components.interfaces.nsIDownloadManager;
gDownloadManager = Components.classes[dlmgrContractID].getService(dlmgrIID);
<<JS code ends>>

and what is the way to see whether the code that I've written(in c++ and also in JS) is getting executed?

I commented some methods(code inside the method) in mozilla\toolkit\components\downloads\src\nsDownloadManager.cpp
and built it, but got no result(Everything was still working fine..)
So how do I TEST which nsDownloadManager.cpp is getting called.. ?
Firefox uses the toolkit version, and xpfe is used by Seamonkey.  I'm fairly certain that this issue is with nsIAlertsService however, and not with the download manager (any alert will do this I'm betting).
And how to i test the my modified code?
Whatever changes i make, they do not get reflected in the built firefox..
for example .. I put (block) comments inside method ShowAlertNotification of toolkit\components\alerts\src\nsAlertsService.cpp
and just added one statement..
	return NS_OK;

So,Now this method does( or should not) not open any alert window..
But when i compile this behaviour is not reflected..

This I have done even for toolkit\components\downloads\src\nsDownloadManager.cpp
Like putting comments in addDownloads..
making GetCanCleanUp return true always..

But nothing seems to be getting compiled and linked to the firefox that i am building...
How do I test that a particular piece of code is getting executed...?
Please help..
if you make a change in toolkit/components/alerts/src/nsAlertsService.cpp, you'll need to remake in toolkit/components/alerts, toolkit/components/build, and if you haven't disabled libxul, you'll need to make toolkit/library as well.
One weird solution to this problem.. 

I've "solved" this problem on my m/c which is running win XP..
Here it is... ( You will not even need source code for this :-) )

YOu will need some (de)compression tool like Winrar.. which can open compressed file (jar to be specific) and update some file inside it.. without explicitly  decompressing it..

Ok.. Now goto Mozilla Firefox\chrome directory.. and open toolkit.jar in winrar (or whichever tool you may have selected)

Inside it, Open content/mozapps/downloads/downloads.js file (Note this file is inside toolkit.jar)
Open it with some editor.. WinRar's default editor is not an editor(it is just a viewer)
and then comment line number -- 476  (I have firefox 2.0.0.7)
Line is something like this..
  gDownloadManager = Components.classes[dlmgrContractID].getService(dlmgrIID);
Just comment it like this..
//  gDownloadManager = Components.classes[dlmgrContractID].getService(dlmgrIID);
Save downloads.js.. WinRar will update toolkit.jar automatically.. It will ask you about the same.. Click on Yes button..

And now open firefox. and try to download something..
You will not be able to see download update(that progress bar) and dont worry..Firefox is downloading the file and just not showing the updates.. Wait for download complete alert.. and see that this time.. it wont take away the focus...

It has worked for me..
But It is not really a solution..
But it tells one fact that (perhaps) nsIAlertService is working fine..
There is some thing in nsIDownloadManager which is taking away the focus on download completion..

Any thoughts.. ?
Assignee: nobody → prafulla.tekawade
Attached patch Patch that fixes this bug (obsolete) — — Splinter Review 
This is the patch which fixes this bug.
It has worked for me..
Here is the description why it works..

Lets first try to understand why at all the focus is taken away when download completes..
It is not actually that alert which takes away the focus..
The focus is taken away by the currently selected download item (inside the download manager)..
When download completes, the _setSelectedItem method gets called with currently selected item and inside this method, aItem.focus() causes the focus to be taken away from whatever currently has the focus..
I added the code in _setSelectedItem of richlistbox.xml to see if the currently selected item and the about to be selected item are same..
If yes we should not give focus to it.. because it already has it.. (and if it does not have it.. it is no big prob( Can anyone test this? ))..
It fixes this bug..
But after adding these lines whenever download manager is selected after download completion, download item does not have the focus..
So I added focus listener in dowload manager.. which gives focus to whichever item is currently selected..
It has worked for me..
Please review it and let me know..
Attachment #282665 - Flags: review+
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
review+ is what someone _else_ sets when they give you an "OK" on your patch; change "review+" to review?", please.
Why did you just arbitrarily change this bug's status from ASSIGNED to RESOLVED WORKSFORME?

Reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Attachment #282665 - Flags: review+ → review?
Reviewer (and everyone) please check if the modifications in richlistbox.xml crashes any other clients of richlistbox...
Status: REOPENED → ASSIGNED
(In reply to comment #45)
> Why did you just arbitrarily change this bug's status from ASSIGNED to RESOLVED
> WORKSFORME?

Sorry I am not much experienced  with bugzilla..
I thought.. If it has worked for me..I should change it...
Sorry!!
I have changed it back to ASSIGNED..
Attachment #282665 - Flags: superreview?
Attachment #282665 - Flags: superreview?
Comment on attachment 282665 [details] [diff] [review]
Patch that fixes this bug

Please generate your diff with more context (generally diffs are generated with -u8p), and don't use tabs.
Attachment #282665 - Flags: review?
Attached patch Fix.patch(With more context) (obsolete) — — Splinter Review 
I have generated patch with more context..
Hope that it will get reviewed...
I gave this command "cvs diff -u8pw > fix.patch".. But it didnt remove the whitespaces..:-(
Attachment #282705 - Flags: review?
You are using tabs with your editor, but they need to be spaces - -w with cvs won't matter for that...
Replaced tabs with spaces
Attachment #282709 - Flags: review?
The patch still adds tabs to the first few files.  You can use http://beaufour.dk/jst-review/ to make sure you've gotten rid of them.
Attachment #282705 - Flags: review?
Attachment #282709 - Flags: review?
Attachment #282709 - Attachment is obsolete: true
Fix.patch(Now no tabs)
Attachment #282665 - Attachment is obsolete: true
Attachment #282705 - Attachment is obsolete: true
Attachment #282796 - Flags: review?
Attachment #282796 - Flags: review? → review?(gavin.sharp)
Comment on attachment 282796 [details] [diff] [review]
Fix.patch(Now no tabs)

Thanks a lot for looking into this, Prafulla! Unfortunately this patch doesn't apply cleanly to the trunk, which is where bugs like this one are fixed first, usually. The richlistbox widget no longer calls focus(), given the changes in bug 298371, and I can no longer reproduce this bug on the trunk. Can anyone else confirm?

We might want to also fix this on the branch if the branch drivers deem it important enough, but that's a bit more complicated. In any case, I'm not sure I understand why the downloads.js/downloads.xul changes are needed.
Attachment #282796 - Flags: review?(gavin.sharp) → review-
:-(
I should have checked the trunk!! I thought the bug was still not fixed..
That's why I took it..
Anyways,  We'll take another bug to work on!! :-)
BTW, About the changes in downloads.js.. See Comment no 43..
And why was this bug still NEW(when I took it) ,when it was already FIXED..?
Someone please mark it as FIXED..
Assignee: prafulla.tekawade → nobody
Status: ASSIGNED → NEW
WORKSFORME as per comment 54.  I'll let Stephen verify...
Status: NEW → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → WORKSFORME
I couldn't reproduce this either, using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007100205 Minefield/3.0a9pre or Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a9pre) Gecko/2007100904 Minefield/3.0a9pre (which I tested with Growl support, just in case).

Verified WFM.
Status: RESOLVED → VERIFIED
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007100905 Minefield/3.0a9pre, rather, instead of 2007-10-02-05, above.
Now the download complete steals the focus of the "Save File Dialog".  This is the same or similar problem not redirected to the "Save File Dialog".  

1) Save a file (about 1-2 MB for broad-band)
2) On another link, Save Link As.
     - Save File Dialog opens
     - Leave it open until the first download finishes.
     
     - the text box where the file name is at will become completely selected
     - you will not be able to press enter to save the file
     - you will have to use tab or your mouse

Jim, please file a new bug report for that.
New bug report created: bug 423856
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: