Closed Bug 405899 Opened 17 years ago Closed 17 years ago

Initiating autoscroll (middle click) causes Firefox to disappear

Categories

(Core :: Widget: Win32, defect, P1)

Product:
Core
Component:
Widget: Win32
Platform:
x86
Windows Vista
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: leaf.of.grass, Assigned: enndeakin)

References

Details

(Keywords: dogfood, regression)

Attachments

(1 file)

guess at a patch
1.03 KB, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007112817 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007112817 Minefield/3.0b2pre

middle-clicking in pages is broken as of sometime today. worked yesterday.

Reproducible: Always

Steps to Reproduce:
1. middle-click inside a scrollable page
2. firefox seems to 'disappear', auto-scroll icon is displayed in upper-left of screen
3.


Expected Results:  
Auto-scroll should work as normal
regress from 20071128_1228_firefox-3.0b2pre.en-US.win32.zip

[range]
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1196280540&maxdate=1196281679
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: unspecified → Trunk
Flags: blocking-firefox3?
Is the autoscroll icon created using a noautohide panel?
SeaMonkey Trunk-Builds (tested Win32 Build 2007112902) are also affected, so this should be set to "Core" and "XP/Toolkit Widgets" I presume.
Keywords: dogfood
Blocks: 395334
I have this bug too, on windows xp, Im using Win32 Build 2007112905, worked fine on Win32 Build 2007112805, 

also about the disappearing i still notice Firefox on the windows task bar but unresponsive, so it's still running. I have to end task it.
Using Spy++ shows that the Minefield window is off the upper-left corner of the primary screen, in the "Maximized" state, sized something like 28px by 28px. The taskbar button is nonresponsive, but by using Task Manager to manipulate the window, Minefield's entire window consists solely of the autoscroll icon, which lives in the upper-left corner of the window regardless of its size. The Windows message pump still runs, as the window responds to messages sent to it, including ones to close.

It's as though the autoscroll icon replaces the *entire* browser UI and window.
I do not see this on Linux with
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007112916 Mnenhy/0.7.5.20004 SeaMonkey/2.0a1pre (self compiled from cvs).
Attached patch guess at a patch — — Splinter Review 
I won't have access to a Windows machine for a few days. Can someone check if this guess at a patch solves the problem?

Bug 395334 shouldn't have had any effect on popups that weren't noautohide panels.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Something else to check. I have been seeing the following:

In the first browser window (maximized) I have open my gmail in one tab and the Trunk forum thread in the 2nd. I open a 2nd browser window (also maximized) for other browsing purposes. While in the 2nd window, it appears that when gmail updates for a newly arriving message, the 1st browser window comes to the front (steals focus?).

I have also seen this if I have something starting to load in one window and switch to the other. The window without the focus will steal it back perhaps based on what is loading into it (like gmail?).

I have not seen this until today's nightly.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007112905 Minefield/3.0b2pre ID:2007112905
(In reply to comment #5)
>  I have to end task it.
Cleaner way to shutdown: left-clicking the autoscroll icon brings up the context menu, from which one can Exit.  


Middle click WFM with this patch applied.
Workaround:
write following style to userChrome.css.

#autoscroller {
  background-color: white !important;
}
The workaround has provided a temporary fix, thanks.
Someone knows if a separate bug for the issue mentioned in Comment 12 has already been filed?
(In reply to comment #20)
> Someone knows if a separate bug for the issue mentioned in Comment 12 has
> already been filed?
> 

The issue described in Comment 12 starts in 20071128_1228_firefox-3.0b2pre.en-US.win32.zip, but does not appear to happen in 20071128_1209_firefox-3.0b2pre.en-US.win32.zip. What I cannot tell is what patch landing is pertinent to the issue described.

The steps to reproduce it are:
1. In a maximized browser window, open a page that automatically update like a gmail inbox.
2. Open a 2nd browser window also maximized. Any "static" page, i.e., a mozillazine forum page.
3. Send a message to the email account open in the 1st underlying browser window. When the email page updates that windows comes forward (steals focus?).

Expected action: Current (2nd) window should not lose focus.

Please feel free to post as a separate bug.
Assignee: enndeakin → nobody
Status: ASSIGNED → NEW
Component: General → Widget: Win32
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → win32
Assignee: nobody → enndeakin
Flags: blocking1.9?
(In reply to comment #26)
> I don't understand this patch.
> 

roc, this was a mistake in the patch for bug 395334. The else clause is what the old code used to do. A popup should not have a parent unless aParent was specified, otherwise Windows thinks the popup is a dependent.
Attachment #290699 - Flags: superreview?(roc)
Attachment #290699 - Flags: review?(roc)
(In reply to comment #15)
> Workaround:
> write following style to userChrome.css.
> 
> #autoscroller {
>   background-color: white !important;
> }
> 

This works for me, but if you change the background-color to "transparent" Firefox does the same thing as if it wasn't even added in.

Given the number of dups (have seen this bug myself) I think we should try and fix for b1
Flags: blocking1.9? → blocking1.9+
Priority: -- → P1
Flags: blocking1.9+ → blocking1.9?
I think this bug should be highest priority, fixed ASAP.
Summary: Initiating Auto-Scroll causes Firefox to disappear → Initiating autoscroll (middle click) causes Firefox to disappear
when is  this bug(405899) fixed?
This one is a Royal show stopper...
Restoring schrep's blocking1.9+
Flags: blocking1.9? → blocking1.9+
Firefox crashed when I was trying to restore the main window after it disappeared:

http://crash-stats.mozilla.com/report/index/19bbb802-a042-11dc-b116-001a4bd43e5c?date=2007-12-01-19
Attachment #290699 - Flags: superreview?(roc)
Attachment #290699 - Flags: superreview+
Attachment #290699 - Flags: review?(roc)
Attachment #290699 - Flags: review+
Whiteboard: [has patch][has review][can land]
Can we check this in asap, please?
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [has patch][has review][can land]
(checked in by ennndeakin on 2007-12-03 06:32)
Flags: in-testsuite?
Confirming WFM now with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120306 Minefield/3.0b2pre ID:2007120306

Haven't tried the gmail issue in comment 12.
Status: RESOLVED → VERIFIED
(In reply to comment #28)
> Filed Bug 406304 on Comment 12.
> 
(In reply to comment #47)
>Haven't tried the gmail issue in comment 12.

See (In reply to comment #28)

Confirming WFM now with:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007120405 Minefield/3.0b2pre
Blocks: 406304
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: