XUL <textbox> is too hard to focus

RESOLVED FIXED in mozilla1.9.1b1

Status

()

P2
normal
RESOLVED FIXED
14 years ago
10 years ago

People

(Reporter: Peter6, Assigned: dao)

Tracking

({testcase})

unspecified
mozilla1.9.1b1
x86
Windows 2000
testcase
Points:
---
Bug Flags:
blocking-aviary1.5 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050329
Firefox/1.0+

repro:
1.Open Firefox (probably the same in Seamonkey)
2.Move the mouse over the locationbar to focus
3.The area that takes focus is only the width and height of the text
4.html <input>, <textarea> takes focus as soon as the mouse is inside the border

This behaviour makes it very easy to miss the focusarea and type stuff that
never is displayed becaused you missed the focus again.

expected:
the XUL <textbox> should accept focus inside the border, like <input> and <textarea>
(Reporter)

Comment 1

14 years ago
Created attachment 178963 [details]
screenshot

Screenshot of where onmouseclick sets focus to the box.
Top: XUL <textbox>
Bottom: html <input type="text"> (same for any other form element)
(Reporter)

Comment 2

14 years ago
? FF1.1 (I'm not sure if that's allowed)

I have been mishitting <textbox> -es way too long
Flags: blocking-aviary1.1?
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050325
Firefox/1.0+

WFM

Comment 4

14 years ago
I thought it was the "Find as you type" bug coming back again. Was that one even
ever fixed? You know, the bug where FAYT just started for no good reason.
(Reporter)

Comment 5

14 years ago
(In reply to comment #4)
> I thought it was the "Find as you type" bug coming back again. Was that one even
> ever fixed? You know, the bug where FAYT just started for no good reason.
This misfocus may well be the reason for FAYT to start

Comment 6

14 years ago
This focus issue is really very irritating, I always have to check twice to make
sure that find toolbar has focus.
(Reporter)

Comment 7

14 years ago
Created attachment 178983 [details]
findbar focusarea loss

I enlarged the Findbar 10 times to show the actuall number pixels that won't
accept focus at mousedown.
(Reporter)

Comment 8

14 years ago
CC Neil Deakin
Any chance you could help us Neil?
(Reporter)

Comment 9

14 years ago
Oops, wrong Neil CC's
This time better (I hope)

Comment 10

14 years ago
I'm not Neil Deakin either but I suspect you'd need to programatically focus the
inner input whenever the mouse is clicked anywhere within the xul textbox;
currently the context menu code has a specific workaround to focus it.
(Reporter)

Comment 11

14 years ago
(In reply to comment #10)
> I'm not Neil Deakin either but I suspect you'd need to programatically focus the
> inner input whenever the mouse is clicked anywhere within the xul textbox;
> currently the context menu code has a specific workaround to focus it.
Boris suggested me to CC you.
I know, an easy hack is adding onclick="focus();" to every textbox , but it
isn't solving the problem offcourse.

Comment 12

14 years ago
(In reply to comment #11)
>I know, an easy hack is adding onclick="focus();" to every textbox, but it
>isn't solving the problem of course.
Then what sort of solution are you looking for?
http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/textbox.xml#97
is a central location where we can add mouse handlers to every textbox.
Note: I would a) prefer to use mousedown rather then click b) directly focus the
inputField c) check that the inputField is not disabled first.
(Reporter)

Comment 13

14 years ago
(In reply to comment #12)
> Then what sort of solution are you looking for?

I am looking for the <textbox> to get focus if mousedown happens anywhere inside
or on the border of the element.
Equal to the mousedown behaviour on any formelement in html

> http://lxr.mozilla.org/seamonkey/source/toolkit/content/widgets/textbox.xml#97
> is a central location where we can add mouse handlers to every textbox.
> Note: I would a) prefer to use mousedown rather then click b) directly focus the
> inputField c) check that the inputField is not disabled first.

I'm a no-coder :-(


taking.
Priority: -- → P2
Target Milestone: --- → mozilla1.8beta2
(Reporter)

Comment 16

14 years ago
Created attachment 179073 [details]
testcase 2

the bottom 2 boxes is how it "should" work.
Target Milestone: mozilla1.8beta2 → mozilla1.8beta3

Comment 17

14 years ago
(In reply to comment #6)
> This focus issue is really very irritating, I always have to check twice to make
> sure that find toolbar has focus.

I have to check twice to make sure it DOESN'T have focus.

Comment 18

14 years ago
Not a blocker, but patches are still welcome.
Flags: blocking-aviary1.1? → blocking-aviary1.1-

Comment 19

14 years ago
*** Bug 289841 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Keywords: testcase
Well, what seems to work for the url bar for me is:
.autocomplete-textbox-container {
  -moz-box-align: stretch; }, instead of -moz-box-align: center;

Comment 21

13 years ago
(In reply to comment #20)
> Well, what seems to work for the url bar for me is:
> .autocomplete-textbox-container {
>   -moz-box-align: stretch; }, instead of -moz-box-align: center;
I thought that was necessary to work properly with large fonts...
Target Milestone: mozilla1.8beta3 → mozilla1.9alpha

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets
(Assignee)

Comment 22

10 years ago
Created attachment 340430 [details] [diff] [review]
patch
Assignee: mano → dao
Attachment #340430 - Flags: review?(enndeakin)
(Assignee)

Updated

10 years ago
Target Milestone: mozilla1.9alpha1 → ---
Comment on attachment 340430 [details] [diff] [review]
patch


>+            if (event.originalTarget == this ||
>+                /(?:\s|^)textbox-input-box(?:\s|$)/.test(event.originalTarget.className))
>+              this.inputField.focus();

Why can't you just add an anonid to the box, or just use this.inputField.parentNode here?
(Assignee)

Comment 24

10 years ago
I'd have to add the anonid to different bindings, let alone bindings that we don't control. But inputField.parentNode seems fine.
(Assignee)

Comment 25

10 years ago
Created attachment 340668 [details] [diff] [review]
patch v2
Attachment #340668 - Flags: review?(enndeakin)
(Assignee)

Updated

10 years ago
Attachment #340430 - Attachment is obsolete: true
Attachment #340430 - Flags: review?(enndeakin)
Attachment #340668 - Flags: review?(enndeakin) → review+
(Assignee)

Comment 26

10 years ago
http://hg.mozilla.org/mozilla-central/rev/60221b1e9513
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b1
(Assignee)

Updated

10 years ago
Component: XUL → XUL Widgets
Product: Core → Toolkit
QA Contact: xptoolkit.widgets → xul.widgets
Version: Trunk → unspecified
(Assignee)

Updated

10 years ago
Depends on: 464084
You need to log in before you can comment on or make changes to this bug.