305706 - After a window.open call, personal toolbar overflow remains when it shouldn't.

Status: VERIFIED DUPLICATE of bug 338803

(Core :: DOM: Events, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Build ID: 2005-08-23-06, Windows XP SeaMonkey.

Summary: After a window.open call, personal toolbar overflow remains when it
shouldn't.

Steps to Reproduce:

1. Have a few bookmarks on your Personal Toolbar.
2. Load the attached testcase and click on the link.
3. Maximize the window that results.

Expected Results:

The personal toolbar should initially overflow (>>), but then on maximize, it
should restore the links back onto itself.

Actual Results:

Personal toolbar overflow remains.

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Testcase

Self-explanatory; see comment 0 for steps.

Comment 2

[Daniel Brooks [:db48x]]

It appears that not all of the resize events are targetting the xul document,
and so they get filtered out at
http://lxr.mozilla.org/mozilla/source/xpfe/components/bookmarks/resources/bookmarksMenu.js#740.
(it's trying to avoid doing too much work, not just ignoring non-chrome events)

If I use the keyboard (alt-f10) or the wm menu to maximize the window, then the
event targets the xul element at the mouse location.

If I make the window large enough that my WM shows me an actual maximize button,
then the bug does not occur because the event targets the xul document.

I'd be nice if we could catch a maximize event coming in from the OS and force
it to target the document, but I don't know where that would have to be done.
Somewhere in widget/ I suppose. neht ,

Comment 3

[[e-mail]]

CCing people who might know if this is a widget or layout regression
(resize events not having the correct target, that is).

Comment 4

[Boris Zbarsky [:bzbarsky]]

Do we have a regression range?

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

*** Bug 307038 has been marked as a duplicate of this bug. ***

Comment 6

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #2)
> It appears that not all of the resize events are targetting the xul document,
> and so they get filtered out at
>
http://lxr.mozilla.org/mozilla/source/xpfe/components/bookmarks/resources/bookmarksMenu.js#740.
> (it's trying to avoid doing too much work, not just ignoring non-chrome events)

Could someone try using the "cached width" method of detecting spurious events
(store the current boxobject.width, and when the resizeFunc is called, compare
the new width to the cached width) and see if that solves it?

Comment 7

[Hermann Schwab]

(In reply to comment #4)
> Do we have a regression range?

This regressed between Windows BuildID 2005081305 and BuildID 2005081716.
I can't tell better as there is no archive of Seamonkey, only Mozilla 1.7.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-13+00%3A00&maxdate=2005-08-17+17%3A00&cvsroot=%2Fcvsroot

I don't know if this bug is related:
Bug 304753  	[FIX]nsImageMap is too eager to invalidate on attribute changes

Comment 8

[[e-mail]]

Weird... for some reason my resize events are getting a current frame.
But the code looks just like those for load events, which work fine...

Comment 9

[Hermann Schwab]

Regressed between Windows 
BuildID 2005081505 and 
BuildID 2005081716

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-15+02%3A00&maxdate=2005-08-17+17%3A00&cvsroot=%2Fcvsroot

I didn't yet check, but if next days build will be regressed, this will be the
timeframe:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-15+02%3A00&maxdate=2005-08-16+06%3A00&cvsroot=%2Fcvsroot

Comment 10

[Hermann Schwab]

Regressed between Windows 
BuildID 2005081505 and 
BuildID 2005081605

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-15+02%3A00&maxdate=2005-08-16+06%3A00&cvsroot=%2Fcvsroot

If this bug is also seen on Linux and Mac, 
there is a Mac build
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2005-08-15-12-trunk/
there is a Linux build
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2005-08-15-23-trunk/

Comment 11

[Daniel Brooks [:db48x]]

Yea, I thought I had set this to all platforms at some point…

Comment 12

[Boris Zbarsky [:bzbarsky]]

Hmm... I see nothing in that range that would cause event targets to change.

And as far as that goes, I see this on Linux with trunk Seamonkey build
2004-07-24-05.

Comment 13

[[e-mail]]

OK, so both bug 20022 and 284664 contribute to this regression, by leaving stale
frames around in the ESM that get picked up by the resize event.

Bug 20022 contributes because it doesn't want to do all the DOM event handling,
but unfortuately fails to match a PreHandleEvent with a PostHandleEvent.

Bug 284664 contributes because the code uses a quick and dirty hack to dispatch
the mouse enter event, which only works in the current ESM because it's in the
middle of dispatching a mouse move event, and the patch made it use the hack in
parent ESMs too, where it leaves a stale frame.

Comment 14

[Boris Zbarsky [:bzbarsky]]

So is this similar to bug 295340 in terms of the event targeting mess?

Comment 15

[[e-mail]]

Well, the resize event fires off a timer, and sees stale frames stored in the
ESM from the mouseover events rather than frames from nested events, but if the
ESM frames are removed to fix bug 295340 then that should fix this bug too.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I just landed the fix to bug 20022 comment 130.

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #16)
> I just landed the fix to bug 20022 comment 130.

Though it's much better now, this still happens occasionally if you resize the
window horizontally, after doing the steps in comment 0.

Comment 18

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Do we want to dupe this to bug 338803?

Comment 19

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #18)
> Do we want to dupe this to bug 338803?

Sorry for the delay; yeah, we do.  It's definitely fixed, at least for me using build 2006-06-06-10 of SeaMonkey trunk on Windows XP. 



*** This bug has been marked as a duplicate of 338803 ***