Closed Bug 312227 Opened 19 years ago Closed 19 years ago

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)

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Version:
1.8 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: frenchfrog, Unassigned)

References

Details

(Keywords: fixed1.8, qawanted, regression)

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.
Blocks: splitwindows
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?
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?
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/
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.
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)
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
>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)
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
-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.
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 ?
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?
my bad, tested in 1.8 branch All test were done in 1.8 branch.
Version: Trunk → 1.8 Branch
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.
(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?
Comment #23, give me a build with the patch for bug 309027 and ill test it.
(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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8rc1? → blocking1.8rc1+
Keywords: qawanted
Aaron, is there a smaller, safer patch we could take to fix this issue?
(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.
Depends on: 309027
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-
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.
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))
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
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
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-
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 ;)
*** 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
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
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: splitwindows
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)
Status: RESOLVED → VERIFIED
Blocks: findgrabs
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.