Not able to type in textbox of the main window after download completes (open find bar if 'Begin finding when begin typing' else the edit commands are disabled)

VERIFIED FIXED

Status

()

Core
DOM
--
major
VERIFIED FIXED
12 years ago
6 years ago

People

(Reporter: François Gagné, Unassigned)

Tracking

({fixed1.8, qawanted, regression})

1.8 Branch
x86
Windows XP
fixed1.8, qawanted, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8rc1 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051008 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051008 Firefox/1.4.1

You cannot type in the textbox on the Firefox main window after a download

Reproducible: Always

Steps to Reproduce:
1.Have the setting to close the download dialog once a download is complete (not
100% sure it's related)
2.Open http://www.mozilla.org
3.Download Firefox
4.Before the download is over, select the download dialog and open the
"Developers" link on http://www.mozilla.org
5.Wait for the download to finish
6.Try to type in the search box of the developers page.

Actual Results:  
The find bar pop instead of writting in the textbox.
(Reporter)

Updated

12 years ago
Blocks: 296639
Keywords: regression
Are you sure this is a splitwindow regression?  And are you talking about a
download dialog (which I doubt Firefox even has anymore) or the download manager
window?
(Reporter)

Comment 2

12 years ago
Sorry, I'm talking about the download manager.

As for the regression of splitwindow, it worked before and it's a focus stealing
problem but I cannot confirm that it's absolutely a splitwindow regression, I
could only say that it have the same symptoms than other bugs marked as splitwindow.
> it worked before

Worked before when?  That is, did this break on the day splitwindow landed?

Ben, is the download manager doing anything interesting with focus() calls?
(Reporter)

Comment 4

12 years ago
hmmm on http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ the lastest
build is from 27 august 2005 and the spliwindow landed on 31 july 2005. I don't
have any older build.

If someone give me a link to a 30 july 2005 build and a 2 august 2005 build I'm
more than willing to confirm (or not) the splitwindow regression.
(In reply to comment #4)
> hmmm on http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ the lastest
> build is from 27 august 2005 and the spliwindow landed on 31 july 2005. I don't
> have any older build.
> 
> If someone give me a link to a 30 july 2005 build and a 2 august 2005 build I'm
> more than willing to confirm (or not) the splitwindow regression.

http://archive.mozilla.org/pub/firefox/nightly/
(Reporter)

Comment 6

12 years ago
2005_09_04_07 works
2005_09_05_06 don't works

If my memory is correct this exactly when a patch to splitwindow was back out
(because it was breaking too many things) just before 1.4 Beta 1 (change from
1.0+ to 1.4).

Also, the current bug is perhaps related to the toaster pop-up indicating the
end of a download.

Comment 7

12 years ago
Comment from Peter van der Woude that ended up in the wrong bug: 

"http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=AviarySuiteBranchTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=20050904+0500&maxdate=20050905+0700&cvsroot=%2Fcvsroot

Francois, I you want to narrow it down I can send you the 
1222 - 1350 -1542 pdt builds for the 20050904"
(Reporter)

Comment 8

12 years ago
Multiple carifications:

1)(I'm sorry, I mess up in comment #6)
2005_09_05_06 works
2005_09_06_17 don't works

I'm willing to do more testing (comment #7)

2)No need to have the setting to close the download dialog once a download is
complete to trigger the bug (?the bug trigger is the toaster pop-up?)

So, is there a setting to disable the toaster pop-up showing when a download is
complete? (for further testing)

3)If you don't have the option "Begin finding when begin typing" enabled, the 
edit commands won't be available to the search box on
http://www.mozilla.org/developer/ (instead of showing the find bar) 

(Reporter)

Comment 9

12 years ago
Further testing,

By removing the toaster pop-up by disabling
browser.download.manager.showAlertOnComplete I still trigger the bug.
2005_09_05_06 works
2005_09_06_17 works

I have the
1513 , 1817(respin) pdt builds of the 5th
0116 , 0537(nightly) , 1447(respin) pdt builds for the 6th
(Reporter)

Comment 11

12 years ago
>2005_09_05_06 works
>2005_09_06_17 works

Peter are not able to reproduce? Are you able to reproduce de bug with the
lastest 1.8 branch build? (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b5) Gecko/20051012 Firefox/1.4.1 ID:2005101212)

Perhaps my instructions are not clear enough?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051013
Firefox/1.4.1 ID:2005101305

I just tried it again ... , no problem

what i did:
1. Start FF
2. Open http://www.mozilla.org
3. Click on download FF
4. Select the file location where to safe the .exe (I used C:\temp\)
5. While FF is loading click on the "Developers" link on http://www.mozilla.org
6. Wait until the "download complete" warning pops up
7. Place the cursor in the searchbox on http://www.mozilla.org/developer/
8. type happily ever after. (meaning no problem)

In Options > Downloads I use:
(*) Ask me where to safe every file (=ON)
[V] Show DM when download begins (=ON)
[ ] Close DM when all downloads are complete (=OFF)
(Reporter)

Comment 13

12 years ago
Are the edit commands available (copy, paste, arrow key navigation) like explain
in comment #8 3)? 
(In reply to comment #13)
> Are the edit commands available (copy, paste, arrow key navigation) like explain
> in comment #8 )? 
Yes, C&P is available from contextmenu and works
and YES I can type w/o a problem
and YES I can move the cursor with the arrowkeys
and YES i have FAYT disabled
(Reporter)

Comment 15

12 years ago
-Clean reinstall (and deleting the remaining directory before reinstall)
-Clean Profile
-0 change of configuration

I can still trigger the bug (no edit comment available) (WinXP only problem?, I
see that you run win2k)

1)Start Firefox
2)Download Firefox (will be put on desktop)
3)Click "Developers" link
4)Don't do anything, don't move the mouse just wait
5)When the download is over, click in the search box type

The edit commands should be not available.
(Reporter)

Comment 16

12 years ago
btw, changing from to another program and going back to Firefox solve the
problem of the edit commands.
That makes this a dupe of one of the "select and focus weirdness" bugs.
And they usually are NOT reproducable by others.
Can you install Console² ( http://forums.mozillazine.org/viewtopic.php?t=318102 )
set "report strict warnings" (under Options) in the javascript console and see
if FF spits out any errors/warnings if you get the focus/select error ?
(Reporter)

Comment 18

12 years ago
Interesseting point to note: With the Console extension the bug don't trigger.
The range in comment 8, assuming that's for branch builds (please always say
what builds you're testing!) corresponds to the checkin for bug 305032 on the
branch.    This is the first patch -- the one aaronlev checked in.

Aaron, could you please take a look at this?
Flags: blocking1.8rc1?
(Reporter)

Comment 20

12 years ago
my bad, tested in 1.8 branch

All test were done in 1.8 branch.
Version: Trunk → 1.8 Branch

Comment 21

12 years ago
I'm not able to duplicate this using the steps in the bug description. WFM NT
5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

In any case, one of the fixes in bug 305032 as actually backing out a change. If
that's what broke this, then it means this was broken before.
Boris, are you talking about the nsWebShellWindow change?

If that's the case I'm suspicious that this would be fixed by bug 309027.
Yes, the webshell window and ESM and focus controller changes.

Comment 23

12 years ago
(In reply to comment #22)
> Yes, the webshell window and ESM and focus controller changes.

Okay, I can't duplicate the bug but I think my theory in comment 21 will hold.
If that's the case then the bug will also have shown up in mid-July builds, and
my change in bug 305032 was only removing an incorrect fix for the bug.

Could someone try the patch in bug 309027 and see if that fixes this?
(Reporter)

Comment 24

12 years ago
Comment #23, give me a build with the patch for bug 309027 and ill test it.

Comment 25

12 years ago
(In reply to comment #24)
> Comment #23, give me a build with the patch for bug 309027 and ill test it.

Check in a few hours at this URL:
ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/accessibility/firefox/firefox-10-17-branch-1.5-win32.exe

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8rc1? → blocking1.8rc1+
Keywords: qawanted
(Reporter)

Comment 26

12 years ago
nice,

ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/accessibility/firefox/firefox-10-17-branch-1.5-win32.exe
works fine.

Comment 27

12 years ago
Aaron, is there a smaller, safer patch we could take to fix this issue?

Comment 28

12 years ago
(In reply to comment #27)
> Aaron, is there a smaller, safer patch we could take to fix this issue?

Asa, sorry. Not that I know of.

Updated

12 years ago
Depends on: 309027

Comment 29

12 years ago
OK. I think this isn't severe enough to risk taking that large a change to a
fragile piece of code this late in the game. 
Flags: blocking1.8rc1+ → blocking1.8rc1-

Comment 30

12 years ago
Peter, did you try typing a '/' into the text box?  For me, just typing letters
is not enough, but '/' triggers the find bar every time. (also windows xp here,
perhaps the bug is xp specific?)

Actually, once Firefox is in this state, more serious symptoms similar to bug
#305032 can be generated by simply switching to another tab.  Paste is disabled,
and Copy is disabled *unless* you had text selected on the first page when you
switched tabs, in which case it will copy that text (even though you're on a
different tab now).  For me, this bug is triggered nearly every time I download
files.  It's been annoying me for months but I didn't realize what was causing
it until now.

I can also confirm that the same bug exists in Firefox 1.5 Beta 1 (before
#305032 was fixed on branch) and it is fixed in the build from comment #25.
(Reporter)

Updated

12 years ago
Summary: [splitwindow] not enable to type in textbox of the main window after download → [splitwindow] not enable to type in textbox of the main window after download (open find bar if 'Begin finding when begin typing' else the edit commands are available (copy, paste, arrow navigation))
(Reporter)

Updated

12 years ago
Summary: [splitwindow] not enable to type in textbox of the main window after download (open find bar if 'Begin finding when begin typing' else the edit commands are available (copy, paste, arrow navigation)) → [splitwindow] not enable to type in textbox of the main window after download (open find bar if 'Begin finding when begin typing' else the edit commands are disable)
Bug 305032 comment 93 says this bug is not being dup'ed, rather 305032 is,
losing information useful for judging severity.

I hit this bug too often, and it's a blocker in my opinion.  *Especially* if we
can back out a patch to unregress this bug (see bug 305032 comment 92) at the
cost of regressing a less severe bug.

/be
I see this on Linux.  Re-nominating, we shouldn't make locally conservative
decisions that conserve more severe regressions than the less severe bugs whose
patch caused those regressions -- when the regressing patch did not face such
conservative release management!

IOW, letting risky patches in a month ago, missing the regression severity
signal, then saying no because the code is fragile, says to me we should not
have taken the patch a month (or so) ago.

/be

Comment 33

12 years ago
I disagree with the assertion that this bug is more severe than Bug 305032. Is
that the bug you are proposing we back out? That was an extremely visible UI
regression that makes copy/edit/paste and other commands non functional when the
OS opens new Firefox windows (as a result of clicking on links in other
applications) which is a very common way for opening up Firefox.

The steps involved for this bug are much less severe and require you to follow a
very specific set of steps. You need to be downloading content in the download
manager, moving focus to the download manager (or opening it if it was not
already open), then waiting for the download to finish without moving focus away
from the download manager, then the download manager is dismissed and now you
can't type in the url bar without manually adjusting the focus.

Is that the issue you are running into all the time or are you running into
something more generic? It's easy to get confused with all of these various
focus issues so I may be misrepresenting the bugs you are talking about. 
Renominating for Brendan (comment 32)
Flags: blocking1.8rc1- → blocking1.8rc1?
I didn't notice the download manager being a cause, but now that you mention it
(uh, and now that I read the bug :-/)... that could be what I do that bites me.
 It's the worst regression from 1.0 that I see.

I download enough lately (PDFs mostly) that this bites me almost every day. 
It's severe, too, in that I can't get focus to work easily (I flail around with
other windows, other apps, tabs, etc. till it works).  It's not something I want
shipped in Firefox 1.5, and I'm not the only or the heaviest downloader.

If we know that we can't fix this, then we should be able to say better what is
going wrong.  Where would we read a description of that?

/be

Comment 36

12 years ago
Lost in the bug noise (at least to me) is the comment that:

Bug #309027 has a patch being worked on which also fixes this but it is a change
to a very fragile piece of code (nsEventStateManager).

(In reply to comment #36)
> Lost in the bug noise (at least to me) is the comment that:
> 
> Bug #309027 has a patch being worked on which also fixes this.

That bug is minused too, and rightly so given the lack of a patch responding to
bryner's last comments.

Can we mark this bug a DUP, or is it testably different from bug 309027?

Aaron, can you take charge and put a new patch in that bug, and deal with this
one?  I'm still bugged by the symptom (whatever bug is to blame), and you are
"it" for now.

mscott: we took the fix for bug 305032 to fix a very visible UI regression, but
what caused that regression?  Some earlier change that was a net change from
1.0.  If we backed out all the late focus-touching a11y work, would most users
be better off?  If we don't make sec508 in Firefox 1.5 anyway, I'd rather have
status quo ante than regressions plus half a loaf.

I don't think this is noise.

/be
Flags: blocking1.8rc1? → blocking1.8rc1-
(Reporter)

Comment 38

12 years ago
clarifications: (I'm the reporter)

-The "Steps to Reproduce" of comment #0 were giving in the optic of 100%
reproductivity not necessarely the shortest path.

(in fact step 1 and the selecting of the download manager of step 4 are facultative)

-The 'wait and do nothing' seem's ridiculous because it's a big file. It's much
more easy to get bitten by that bug when downloading small files because the
wait time is much shorter.

-I fall on this bug once in a while (and i'm not downloading much in firefox) so
I guess someone downloading a lots will get hit a much more, duh ;)

Comment 39

12 years ago
*** Bug 312394 has been marked as a duplicate of this bug. ***
This should now be fixed on both MOZILLA_1_8_BRANCh and trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8
Resolution: --- → FIXED

Comment 41

12 years ago
Fixed by the patch in bug 309027.

This turned out to be a regression from bug 307153, not from split window.
Blocks: 307153
No longer blocks: 296639
Summary: [splitwindow] not enable to type in textbox of the main window after download (open find bar if 'Begin finding when begin typing' else the edit commands are disable) → Not able to type in textbox of the main window after download completes (open find bar if 'Begin finding when begin typing' else the edit commands are disabled)
(Reporter)

Updated

12 years ago
Status: RESOLVED → VERIFIED

Updated

12 years ago
Blocks: 320465
You need to log in before you can comment on or make changes to this bug.