158001 - Ctrl+Mouse Wheel events go to wrong window

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[R.B.]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020715
BuildID:    2002071507

I see this with recent branch builds, I haven't tried with trunk. In some
circumstances Ctrl+Mouse Wheel events go to the wrong window. To start, have in
Preferences enabled: Mouse Wheel > Control > Make the text larger or smaller.

Reproducible: Always
Steps to Reproduce:
1.Open two windows with some pages. In one, right click on a link and select
Open Link in New Tab.
2.Quickly activate the other window and wait. When the page in the first window
starts loading, the window will jump into foreground. (Comment: Why?? This looks
like a bug itself, but I couldn't find any. Or, is it configurable ?)
3.Bring the second window in foreground again, and do Ctrl+Mouse Wheel.

Actual Results:  The fonts in the first window (now in background!) will be resized.

Expected Results:  The fonts in the second (foreground, focussed) window resizes.

Note that using mouse wheel without modifier will correctly scroll the second
(active) window.

Debian, XFree 3.3.6, Windowmaker here.

Comment 1

[R.B.]

The autoraising to foreground of the window in which a link has been opened in a
new tab (as described in Step 2) has been reported in Bug 159002.

Comment 2

[Jean-Philippe Martin]

I have tried to reproduce this bug without success, using both

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722
and
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020806

I see the raising you describe in point 2, but only if some other window has
focus, not the second nor the first Mozilla window.

Every time I tried the fonts in the second window (correctly) changed size.
Maybe this is due to the different window manager I'm using?

Debian XFree 4.1.0.1, Sawfish/gnome here.

Comment 3

[Philip White]

R.B., does this problem still occur for you with the most recent release/build
of Mozilla?

Comment 4

[R.B.]

I tried to reproduce it (Linux 1.4a, 20030312), and (to my surprise) the bug is
still there! I had not noticed it for a long time, but that's probably because I
changed my browsing habits.

It would be nice if somebody else could reproduce it. I hope that my Steps to
Reproduce are intelligible. Note that it may depend on the fact that I am on a
slow (modem) link, so that the timings are right, in particular the page in the
newly opened tab should not start rendering too soon (i.e. not before the second
Mozilla window is activated).

Comment 5

[R.B.]

Oops, I accidentally marked the bug as WORKSFORME, now marking as REOPENED
again! Sorry for the Bugspam.

To make this comment useful, I add that the bug does not show every time. In
particular, the second window must almost entirely cover the first one,
otherwise the new tab will not autoraise when the rendering starts, and the
ctrl-mousewheel will not be delivered to it (after it being covered by the
second window again). If still not clear, I can attach a screenshot with an
explanation.

Comment 6

[Alexander Opitz]

Reporter can you reproduce this bug with a newer build (1.4 final)?
If not, then please close this bug as worksforme. Thanks.

Comment 7

[Daniel Wang]

no response -> wfm