160398 - cvshome.org - font resize moves link text before button release event

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Brent]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020722
BuildID:    2002072204

Can't click to follow some links because a font size change causes a page layout
change which moves the link text away from the pointer after the button press
and before the button release.

Reproducible: Always
Steps to Reproduce:
1.  Go to the CVS website and browse the manual
2.  Adjust size of browser window so the link
"7. Adding, removing, and renaming files and directories"
barely fits on one line.
3.  Click on that link.

Actual Results:  After a click, the font of the link grows and the text to the
right is rejustified as if the link text was still being put on one line.  This
causes the link text to shift down a line.  Then the link text is split into 2
lines which leaves a column of unused space several characters wide.  The link
text is no longer under the mouse pointer when the mouse button is released, so
the link is not followed.  After the link is not followed, the font size and
layout change back.

Expected Results:  Should be able to click to follow the link.  Link should not
move away from the mouse pointer in the middle of a mouse button press and release.

Comment 1

[Boris Zbarsky [:bzbarsky]]

The problem is that the mousedown (_not_ the mouseclick) puts the link in the
:active state and the site designer has decided that :active links should be
bold (and hence should reflow and move).

What we're doing is correct as far as I can tell... (it's just like the designer
deciding that mousedown on a link should hide the link).

Comment 2

[Brent]

That CVS manual page has some kind of column structure.  The problem is that the
browser is both widening the column containing the link text AND splitting the
link text into 2 lines so that it fits into the original column width. 
Shouldn't need to do both.  If the browser only widened the column, the columns
to the right would still change and the link text would still move away.  Seems
like rebreaking the lines and keeping the original column width would work as
then only those elements below the link would change position.  Or, could the
window be scrolled so that whatever element was beneath the pointer before the
mousedown event is still there after the mousedown event?  I tried moving the
mouse pointer to the link before releasing the mouse button, but all that did
was make the browser think I wanted to drag the link text.  And, BTW, why should
drag work in this situation but not mouseup?

On the window scrolling notion, to what fixed point does the page layout process
refer when laying out the page?  The upper left corner of the document?  Or is
the upper part whatever element happens to be at the top of the window, so that
if one is not at the top of the document, reflowing could cause the offscreen
part to change size and therefore the browser has to adjust the position of the
scrollbars to keep whatever element was in the upper left of the window in the
upper left?  Maybe it should use the pointer position instead?

Checked IE 5.0.  Behaves exactly the same as Mozilla.

This is definitely a bug, but one can argue it's in the web page, not the
browsers.  But I think if there's a sensible way to do so, browsers should
accomodate web pages that do this.  Using the mouse pointer position as the
fixed reference point I think would be the best solution.  A final (and I
suppose unfair) point:  Lynx doesn't have any problem with this.  For that
matter, neither does keyboard focus, and one can access the link by tabbing
until that link has the dotted box around its text and then hitting Enter.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> to what fixed point does the page layout process refer when laying out the page

Top left of page, generally.

> Lynx doesn't have any problem with thi

Lynx also does not support the CSS involved, last I checked (and typically uses
fixed-width fonts for which the whole thing is a non-issue).

I'm not sure that there is a good way of defining "pointer position" as you use
it in your suggestion....

Comment 4

[Brent]

pointer_line = vertical offset (in pixels? from start of document)
of line containing
1. text that would be selected (highlighted) if mouse button double clicked
or 2. link that would be followed if mouse button clicked
or 3. image, java app window, etc. that would be selected

pointer_element = offset into HTML source of pointer_line

if (reflow_needed) {
  saved_pointer_line = pointer_line;
  saved_pointer_element = element (text, link, etc.) under pointer;
  reflow();
  new_pointer_line = find_line_containing(saved_pointer_element);
/* best if the reflow process could flag the new location, then
   don't have to go to a lot of effort here to find where something got to:
  new_pointer_line = reflow(saved_pointer_element); */
  if (new_pointer_line != saved pointer_line) {
    vertical_scroll (pointer_line - saved_pointer_line);
/* positive value == scroll down, negative value == scroll up */
  }
}

This would also be nice for the "Ctrl +" and "Ctrl -" keypresses.
Horizontal scrolling may not be desirable (or easy).

Is this change to Mozilla really that hard to do?

Comment 5

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

->evangelism, since I suspect the style rule causing this doesn't work correctly
in any other browsers, so it may be unintentional

Comment 6

[Tristan Seligmann]

Mozilla's behavior here seems to be correct. In addition, the page has
apparently been changed to avoid this problem (links do not become bold
anymore), so this bug should be closed, or marked as a future enhancement.

Comment 7

[Frankie]

CVSHome changed their CSS so the links don't run away.