263346 - find toolbar deforms page with relative-height frames so click on link doesn't always work

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[posita]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10

I don't know if this happens on other platforms, but on 1.0PR on OS X, in some
cases, the presence of the find toolbar deforms some frames just enough to
change the positioning of the text they contain. When you click on a link in one
of those frames, the find toolbar disappears and the text position returns to
what it was sometimes moving the link you just clicked on. Firefox behaves as if
you "missed" it.

Reproducible: Always
Steps to Reproduce:
1. Go to a page with frames. This one works well:

    http://java.sun.com/j2se/1.5.0/docs/api/index.html

The rest of the steps assume you're using this page.

2. Type "java" to display the find toolbar. Make sure to get this right the
first time. If you mistype (e.g., jvaa), reload the page and start over because
it may find something else, and the remainder of my steps won't necessarily make
sense.

At this point, you may have noticed that the size of the stacked frames on the
right have changed slightly to accomodate the find toolbar (I think they're
page-relative, so with the reduced area, they both shrink to maintain their
appropriate ratios). This is fine for the frame on top, but you may have also
noticed that the absolute vertical position of the text/links in the bottom
frame has changed (it moved up).

3. Click on the top of any of the links in the bottom frame. By "top of the
link" I mean towards the top of the text. For example, if I were to click on the
"AbstractAction" link, I would click near where the two lines meet at the top of
the capital "A" or on the dot in the lowercase "i".
Actual Results:  
When you click, the find bar disappears, and the absolute position of the links
in the bottom frame are restored, moving the link you wanted to select out from
under you. By the time the mouse is released, you are no longer over the link,
and it doesn't register as being clicked (although it is highlighted from the
selection when the mouse button was pressed).

Expected Results:  
I was expecting the link that I thought I clicked to actually be followed.

I think I understand what is happening here: It's very similar to pressing the
mouse down briefly on the link, moving off it and releasing the mouse button.
However the action in this case is involuntary because of the movement of the page.

I'm not sure if making the disappearance of the find toolbar coincident with the
mouse button being released (instead of just pressed) would fix this, but it
seems like a good idea without looking at the code or knowing anything about
side effects, etc., etc. :-)

Comment 1

[Tuukka Tolvanen (sp3000)]

(linux firefox aviary 20041007) Clicking on link in bottom left frame when find
bar is visible, hides find bar and thus resizes that frame, causing the clicked
link to move upward away from under the mouse pointer. The link clicked on loads
fine for me, though, unless I make it a very long click.

Comment 2

[posita]

I'm not Quick-Draw McGraw, but no matter how fast I click, I can't seem to get
the thing to fire if it is no longer under the pointer after the find toolbar
closes (on OS X at least).

Comment 3

[Michael Clackler]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041001
Firefox/0.10.1

I can duplicate this on Windows XP.  I'll look into it, I saw some code that
might be causing this problem.  Instead of closing the "typeahead" findbar when
a link is first clicked, we should close the bar when the new page first begins
to load.  This would eliminate the "resizing" of the window which causes the
problem.

Comment 4

[posita]

That sounds okay, but be aware that if one takes the approach of only closing it
after a link is selected, then one forces the user to explicitly close it if
they just click on the background or some text or something. That is unless one
addresses the other non-link cases with another behavior, but that begins to
sound like spaghetti.

This may also have confusing effects when opening links in new windows/tabs. For
example, what would happen if a user had the find toolbar open and right-clicked
on a link and selected "Open in New Tab"? What if the user selected a link that
used JavaScript to open a popup?

It seems to me that a more consistent behavior would be to close the find
toolbar when the mouse button is released outside of the toolbar which is very
similar to the current behavior (except that it would occur on mouse-up as
opposed to mouse-down), but I don't know how much more difficult this would be
to implement.

Just my (uninformed) $0.02.

Comment 5

[Michael Clackler]

Attachment: patch to fix

This patch changes the automatic closing of the "FAYT" find bar from on a
mousedown event to a mouseup event.  This fixes the problem outlined above.

Comment 6

[Michael Clackler]

Attachment: Fixes problem with URL selection not working due to closing findbar [Checked in: Comment 13]

Same basic patch as last time, just updated for new findbar.js	Patch closes
findbar opened with FAYT, ', or / on mouse-up instead of mouse-down.

Comment 7

[logan]

Nice job, the patch works great.

It's been a few months, dunno if Blake is busy or what... Maybe when 1.1 draws
near we can nominate this for a blocker, it's totally irritating. :P

Comment 8

[logan]

This appears to be fixed on trunk, should this bug be closed or is it being kept
open for 1.0.x?

Comment 9

[Mike Connor [:mconnor]]

hmm, this has a downside too.

need to think about stuff with context menus, which are onmousedown on Linux.

Comment 10

[logan]

(In reply to comment #9)
> need to think about stuff with context menus, which are onmousedown on Linux.

Is there some side effect I don't see or are you just talking about continuity?
Most Gtk apps I've used work on button release, but it's annoying to have clicks
do nothing, so I'd like to see this stay. :)

Comment 11

[Tuukka Tolvanen (sp3000)]

(In reply to comment #10)
> (In reply to comment #9)
> > need to think about stuff with context menus, which are onmousedown on Linux.

> Most Gtk apps I've used work on button release, but it's annoying to have 

not sure what you mean there, but e.g. nautilus, gnome-terminal, gedit, gimp,
and firefox do display context menus on mousedown, not release.

I do get the correct context menu for a link item in the testcase even when the
link moves away from under the mouse by the findbar closing, on trunk 20050505
gtk2 fx. Interestingly, the context menu is initially on the screen coordinates
clicked on, but when hovering over the "This Frame" item on it (the only item
with a submenu) it moves to the document coordinates clicked on (i.e. down a bit).

Comment 12

[:Gavin Sharp [email: [e-mail]]]

Michael, think you could maybe make a push to get this checked in? Asking on IRC
is usually the easiest way.

Comment 13

[Daniel Brooks [:db48x]]

fix checked in