79961 - Resizing outliner column width makes other columns collapsed to minimum.

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[doctor__j]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9+) Gecko/20010507
BuildID:    2001050720

Reproducible: Always
Steps to Reproduce:
1. Go to any URL with some image.
2. Choose "View menu -> Page Info".
3. Select "Images" tab.
4. Try to resize a column width (say Image URL).
5. When resizing, drag the column separator to left or right by *one pixel*,
holding the mouse button still.  (Large enough to trigger the resize action, but
small enough to prevent the buggy effect from disappearing).
6. See the other columns on the right all shrinked to mininum width.
7. When you drag the column separator further away, the effect will get away.

Actual Results:  If you release the mouse button after doing step 6, the effect
will stay there, making all columns to the right shrinked to minimun width.

Expected Results:  Changing a column width will not affect the width of the others.

Comment 1

[doctor__j]

Attachment: Screenshot after performing Step 6

Comment 2

[doctor__j]

Attachment: Screenshot after performing Step 7

Comment 3

[Daniel Brooks [:db48x]]

ahh, yes. gotta love those trees. They have a number of nice little bugs like that.

Comment 4

[Alfonso Martinez]

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

Comment 5

[Matthias Versen [:Matti]]

-> Default owner

Comment 6

[John Morrison]

Weird. Mostly harmless and is recoverable with further resizing. Someday,
this dialog needs to get off of <tree>, but as for fixing <tree> ... future.

Comment 7

[[not reading bugmail]]

another reason I filed a bug for side scrollers: bug 103543

Comment 8

[risto.kankkunen]

Attachment: Translate coordinates relative to frame, for testing

Comment 9

[risto.kankkunen]

Attachment: Let inner frames get events, for testing

Comment 10

[risto.kankkunen]

It seems that when you click with the mouse, you always get both a button down
and a mouse move event.

When clicking between the outliner header columns, this initial mouse move event
gets to the splitter between the columns. However, the location of the event is
not given in the splitter's coordinate space but untranslated. Thus it seems to
the splitter that the mouse has moved far to the right and it tries to follow it.

The guilty part here seems to be nsPresShell::HandleEventInternal() around line
5830. See
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsPresShell.cpp#5826.
Attachment 58022 [details] [diff] contains a proof-of-a-concept patch translating the coordinates
before the call. This patch removes the column resising problems. It's strange
how well everything works even with the wrong coordinates...

Because we are doing again the same calculations here than in
GetFrameForPoint(), a better way to fix this would seem to make
GetFrameForPoint() return not only the frame but also the transformed
coordinates. This of course requires bigger changes...

Why then only spliters in outliners have this problem? It seems that with the
other splitters, the initial move event is consumed by the frame inside the
splitter. However, in outliners the splitters have a width of zero and
furthermore the inner frame doesn't cover the whole splitter. Thus the inner
frame doesn't get hit by the event. Attachment 58023 [details] [diff] contains a patch to
illustrate this. It assigns a width to the splitters on the fly and makes sure
we ask for a point inside the inner frame. This hides the bug, but the poor
inner frame still gets events with wrong coordinates.

Btw. The second patch has any effect only on the outliners of course, e.g. the
ones in mailnews I reported this problem about in bug 95865 but which was then
duped to this. The first patch seems to fix also the case described in this bug 
although it is using trees, not outliners, as I just discovered...

I hope this analysis isn't totally off and is of use to somene in fixing this. I
don't know the event code well enough yet to do it myself...

Comment 11

[John Morrison]

cc: evaughan for splitters

Thanks risto for looking at this. Your earlier bug probably shouldn't have been 
duped against this one, since this bug was thought to be just for <tree> (which 
is going away) and not for outliner (which will become the new <tree>).

This is, as you note reproducible in, e.g., the mailnews threadpane outliner.
If you just move a splitter 1 px, then all columns to the right will collapse 
to their min-width.

I'll leave it to hyatt and evaughan to digest your suggestion, but for now, 
unsetting the milestone. This seems like a basic (if quirky) defect in outliner
that should be considered for a fix before the 1.0 timeframe.

Comment 12

[Daniel Brooks [:db48x]]

at any rate, the trees in page info be replaced with outliners soon enough, see
bug 52730

Comment 13

[risto.kankkunen]

I agree with what you say about duping the bug, but at the same time want to
point out that if my analysis is right, then the problem is not with outliner or
tree but somewhere else and both are fixed with something like I have in
attachment 58022 [details] [diff] [review].

However, I have to warn that the same patch makes clicking into browser window
do some strange things (it scrolls to the top like you were dragging the mouse).
I'll try to see what's going on there. I hope there is just some workaround code
in the browser for the wrong coordinates that now misbehaves when the underlying
problem is fixed...

Comment 14

[John Morrison]

-> evaughan, splitters.

Comment 15

[Asa Dotzler [:asa]]

0.9.6 is long gone. -> 0.9.7

Comment 16

[Sean Su]

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

Comment 17

[R.K.Aa.]

dup of bug 95872?

Comment 18

[John Morrison]

This same defect leads to ugly 'flash' when you resize columns (i.e., I think 
that the columns are instantaneously collapsing to 1px then reexpanding to the 
dragged width, and the quick collapse/expand flashes the text). 

This is such a basic defect in the outliner that I think we should consider 
fixing it for nsbeta1.

-> trudelle, cc: varga (if you want to have a look)

Comment 19

[John Morrison]

unset milestone, add nsbeta1

Comment 20

[Peter Trudelle]

->varga

Comment 21

[Peter Trudelle]

nsbeta1+ per Nav triage team, Nav3, ->1.0

Comment 22

[Jan Varga [:janv]]

<tree> and <outliner> use almost the same code for getFrameForPoint()
so this bug should be visible in both.

I'll look if this is a tree/outliner bug or splitter or anything else.
I suspect that there may be some uninitialized value.

Comment 23

[Jan Varga [:janv]]

Attachment: fix

Capture mouse events right after mouse down (not after first mouse move)

Comment 24

[Brian Ryner (not reading)]

Comment on attachment 75955 [details] [diff] [review]
fix

r=bryner

Comment 25

[Blake Ross]

Comment on attachment 75955 [details] [diff] [review]
fix

sr=blake

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 75955 [details] [diff] [review]
fix

a=roc+moz

Comment 27

[Jan Varga [:janv]]

fix checked in