314893 - Downloads complete popup steals focus from active text entry boxes

Status: VERIFIED WORKSFORME

(Toolkit :: Downloads API, defect)

Description

[Mikhail Stukalov]

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.

Comment 1

[Ria Klaassen (not reading all bugmail)]

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.

Comment 2

[Adam Guthrie]

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?

Comment 3

[Scott MacGregor]

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!

Comment 4

[Jesse Ruderman]

I want to know whether this bug is a recent regression and how many users it affects.  It sounds a lot like bug 312227...

Comment 5

[Sokraates]

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

Comment 6

[Ria Klaassen (not reading all bugmail)]

It is a regression:
1.9a1_2005090206 - 1.9a1_2005090222
1.8b4_2005090605 - 1.8b4_2005090613

Comment 7

[Jesse Ruderman]

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?

Comment 8

[Ria Klaassen (not reading all bugmail)]

(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. 

Comment 9

[Ria Klaassen (not reading all bugmail)]

Tested it on a brand-new profile with default settings (first run).

Comment 10

[Mike Connor [:mconnor]]

Attachment: hacky workaround for focus (set focus when window gets focus)

going to test this on a clean tree, but seems to work ok

Comment 11

[Mike Schroepfer]

Seems like a low-impact issue that will not block rc2.

Comment 12

[Adam Guthrie]

*** Bug 315919 has been marked as a duplicate of this bug. ***

Comment 13

[mark]

It's pretty annoying bug. Definately should be a blocker!

Comment 14

[Jerome Dahdah]

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.

Comment 15

[john jack]

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.

Comment 16

[Blake Kaplan (:mrbkap) (inactive)]

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.

Comment 17

[Daniel Veditz [:dveditz]]

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.

Comment 18

[Ria Klaassen (not reading all bugmail)]

*** Bug 337591 has been marked as a duplicate of this bug. ***

Comment 19

[Lloyd Wood]

Focus is also stolen from other applications. See Bug 337591 (duped to this) for a description of that.

Comment 20

[Jim]

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. 

Comment 21

[k]

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. 

Comment 22

[Mike Connor [:mconnor]]

Too late to play around with focus.

Mats, a trunk patch sooner rather than later would be great.

Comment 23

[Adam Guthrie]

*** Bug 353809 has been marked as a duplicate of this bug. ***

Comment 24

[k]

Any update? Has this been fixed in the RCs?

Comment 25

[Ria Klaassen (not reading all bugmail)]

*** Bug 358048 has been marked as a duplicate of this bug. ***

Comment 26

[Martijn Wargers (dead)]

*** Bug 360655 has been marked as a duplicate of this bug. ***

Comment 27

[Phil Ringnalda (:philor)]

*** Bug 364825 has been marked as a duplicate of this bug. ***

Comment 28

[Olaf van der Spek]

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?

Comment 29

[Erik Neff]

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.

Comment 30

[Joachim Noreiko]

(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).

Comment 32

[Ihar 'Philips' Filipau]

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.

Comment 34

[Stephen Donner [:stephend] Not actively reading bugmail]

http://litmus.mozilla.org/show_test.cgi?id=4606

in-litmus+

Comment 35

[Prafulla]

(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 ?

Comment 36

[Shawn Wilsher :sdwilsh]

(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.

Comment 38

[Prafulla]

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.. ?

Comment 39

[Shawn Wilsher :sdwilsh]

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).

Comment 40

[Prafulla]

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..

Comment 41

[Shawn Wilsher :sdwilsh]

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.

Comment 42

[Prafulla]

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.. ?

Comment 43

[Prafulla]

Attachment: Patch that fixes this bug

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..

Comment 44

[Stephen Donner [:stephend] Not actively reading bugmail]

review+ is what someone _else_ sets when they give you an "OK" on your patch; change "review+" to review?", please.

Comment 45

[Stephen Donner [:stephend] Not actively reading bugmail]

Why did you just arbitrarily change this bug's status from ASSIGNED to RESOLVED WORKSFORME?

Reopening.

Comment 46

[Prafulla]

Reviewer (and everyone) please check if the modifications in richlistbox.xml crashes any other clients of richlistbox...

Comment 47

[Prafulla]

(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..

Comment 48

[Shawn Wilsher :sdwilsh]

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.

Comment 49

[Prafulla]

Attachment: Fix.patch(With more context)

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..:-(

Comment 50

[Shawn Wilsher :sdwilsh]

You are using tabs with your editor, but they need to be spaces - -w with cvs won't matter for that...

Comment 51

[Prafulla]

Attachment: Fix.patch(Replaced tabs with spaces)

Replaced tabs with spaces

Comment 52

[Jesse Ruderman]

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.

Comment 53

[Prafulla]

Attachment: Fix.patch(Now no tabs)

Fix.patch(Now no tabs)

Comment 54

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 55

[Prafulla]

:-(
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.. 

Comment 56

[Shawn Wilsher :sdwilsh]

WORKSFORME as per comment 54.  I'll let Stephen verify...

Comment 57

[Stephen Donner [:stephend] Not actively reading bugmail]

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.

Comment 58

[Stephen Donner [:stephend] Not actively reading bugmail]

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.

Comment 59

[Jim]

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

Comment 60

[Jesse Ruderman]

Jim, please file a new bug report for that.

Comment 61

[Jim]

New bug report created: bug 423856