153069 - mouse clicks in url field often ignored

Status: RESOLVED EXPIRED

(SeaMonkey :: Location Bar, defect)

Description

[Jamie Zawinski]

It's hard to describe this bug, since I suspect it's actually several bugs.  The
effect I see/feel is that, I have clicked in the text in the URL bar to move the
cursor, started typing, and then found that the cursor hadn't moved at all.

I have found at least one reproducible case of this frustration:

  - double-click in the URL bar to select everything
  - hit backspace
  - in another app, select the text "http://www.jw.org/"
  - middle-click in the URL bar to paste that text
  - click between the "w" and the "."
  - type "z"
  - note that you have ended up with "http://www.jw.org/z"

This is because at the paste, the "completion" drop-down menu was popped up, and
the click merely dismisses that menu.  That click should *also* move the cursor.
 Or perhaps it should move the cursor without dismissing the menu; either way.

I also find that there is a lot of dead space inside the rectangle: the URL bar
text field is a black rectangle filled with white, with the URL text centered in
it.  However, not all of that white area is clickable: pretty much only the area
out to the edge of the font ink is clickable, and the interior margin is not. 
This is very frustrating, as that's a very small target, and there is no visual
distinction between what is clickable and what is not.  

Here's an ASCII graphic to try to clarify.  As far as I can tell, only the areas
shaded with "......" accept mouse clicks to position the cursor.  I think that
*all* the area inside the rectangle should accept cursor-positioning clicks:

          =======================================================
        ||                                                       
        ||              .........................................
        ||  \\\         ..##......##....##.................##....
        ||   \\\        ..##.....####..####..####...##....##.....
        ||    \\\       ..#####...##....##...##.##.......##......
        ||     \\\      ..##..##..##....##...##.##..##..##.......
        ||      \\\     ..##..##..###...###..####......##........
        ||       \\\    .....................##..................
        ||                                                       
        ||                                                       
          =======================================================

In addition to the top and bottom margins, the left and right margins, and the
space taken up by the "favicon" are also a problem: it's exceedingly hard to
position the cursor before the first character in the URL.  There's a very small
invisible target there that you have to reach: the target is only half the width
of the "h" character, and ends *exactly* at the leftmost pixel of the H, despite
there being 8-10 pixels of visible whitespace between the favicon and the h.

Similar problem on the right side, with the drop-down arrow, when the URL is long.

Comment 1

[Jamie Zawinski]

See also related but non-identical bug 153766.

Comment 2

[Andrew Hagen]

Seeing this on Windows trunk build 2002071704. PC/All.

Comment 3

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 4

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420