385478 - Focus problem when restoring a minimized window using the Windows taskbar

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Martijn Wargers (dead)]

To reproduce the bug:
- Open url
- Select all on the page (by pressing ctrl-A for instance)
- Minimize Firefox and drag a local html file in the document
- Go back
- Open a new tab
- Right-click to open the context menu

Expected result:
Normal context menu for a newly opened blank document

Actual result:
"View selection source" context menu

For some reason, I'm only seeing this when I have Show: "Icons and Text" set in "Customize Toolbar".

Comment 1

[Brian Polidoro]

Martijn

This step is not making sense to me:
- Minimize Firefox and drag a local html file in the document

How can you drag something on Firefox if it is minimized?  Do you mean unmaximize the window?

I've also seen this context menu problem.  Another problem I've seen that seems to coincide with this is not being able to scroll all tabs except one with keyboard commands.  The keyboard commands would always scroll the one tab even if it was in the background.  Do you see that?  

I was still missing the trigger to this problem so I didn't file a bug yet.  

Comment 2

[Martijn Wargers (dead)]

Yeah, unmaximizing the window should also work to trigger the bug.
But what I normally do is minimize all windows, and then drag the html file on the program item on the desktop toolbar, wait a little while, then the window usually pops up.

Comment 3

[Brian Polidoro]

Ok I had not done that before.  So I didn't know it would do that.  Now I can reproduce it.  And if you load a site in that new tab you can't scroll with the keyboard.  The keyboard commands go to the tab where everything was selected with Ctrl-A.  

Comment 4

[Brian Polidoro]

Thanks to the reproducible steps:
Regression Range:
20070616 ok
20070617 broken

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-06-16+04%3A00%3A00&maxdate=2007-06-17+04%3A00%3A00&cvsroot=%2Fcvsroot
which corresponds with the backout of Bug 261074.  

Comment 5

[gabe]

https://bugzilla.mozilla.org/show_bug.cgi?id=379148

maybe they are linked in that both prevent you from selcting something and 261074 patch seems to toggle them

Comment 6

[Brian Polidoro]

I finally have a simpler and much more common way to reproduce this.  I hit it many times a day.

1. Have multiple tabs open. 
2. Note that all tabs can be scrolled using keyboard commands.
3. Minimize Minefield
4. Restore Minefield - it is crucial that you use Minefield's taskbar entry to restore the window by either left clicking on the taskbar entry or right clicking on it and selecting Restore or Maximize. 
5. Now the active tab will scroll with keyboard commands.  But keyboard scrolling commands will not work in other tabs.  In fact the commands will affect the former active tab even when it is not active.  The context menu will also depend of the state of that tab. 

One way to get out of this state is to alt-tab to another application and then alt-tab back.  Or focus one of Minefield's other windows like the addons window.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

If this is a regression from the backout of bug 261074, it's not really a regression (just temporarily working). Could someone please clarify if that is the case? I.e. does this work in FF2 or not?

Comment 8

[Brian Polidoro]

Trying either of the sets of steps above does not result in a focus problem in FF2.  I went back to the build before bug 261074 was checked in (02-19-2007) and the problem doesn't exist there either.  So I guess bug 261074 was masking when the real regression was checked in.  

Or maybe that's not the case either.  Something that seems fishy to me is from looking back at the check-ins that are from between bug 261074's landing and backing out is that Bug 372177 and Bug 371564 were checked in as regression fixes for bug 261074.  Shouldn't they need to be backed out too?  From what I can tell Bug 372177 was effectively backed out even if it wasn't meant to be done but Bug 371564 wasn't backed out.  Maybe that's the culprit here.  

Comment 9

[gabe]

 Bug 371564 anybody care to back it out see if it changes anything

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Oliver, could you test if this is a regression from your fix to Bug 371564?

Comment 11

[Martijn Wargers (dead)]

Attachment: testcase

This is also a case where I see this problem occuring.
You need to download this file to your computer and then drag the file from a minimized Firefox window to see the bug.
I got this testcase while trying to come up for an issue in bug 280959.

Comment 12

[Brian Polidoro]

The problem seems to be gone now that bug 371564 was backed out in bug 261074.

Comment 13

[Martijn Wargers (dead)]

Yeah, this is no problem anymore with current trunk build.
Thanks for the heads up.
It was fixed between 2007-08-28 and 2007-08-29.
That corresponds with the backout in bug 261074.