52815 - remove 3rd tab in an input[type="file"] form element tab cycle order

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[James Lariviere]

DESCRIPTION:

extra tab in an input[type="file"] form element.

STEPS TO REPRODUCE:

view a test case I have for bug # 41819.
(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=12896)

ACTUAL RESULTS:

As you tab through the form elements notice that the input[type="file"] does not
work as anticipated in that it takes 3 tabs to go through (1) for file path (2)
the button (3) whatever is "behind" the button. WIERD!

EXPECTED RESULTS:

I would think you tab through (1) file path (2) the button, than go onto the
next form element.

DOES NOT WORK CORRECTLY ON:

Win98 build 200091505 (9-14-00 nightly build I think)

Comment 1

[bsharma]

Updating QA contact.

Comment 2

[James Lariviere]

Rod,

per your comments on bug 52813.

I changed the summary.

Currently nav4.08 tabs through the input file in one tab (ie5 in 2 tabs, [input
then button], and mozilla takes 3 tabs.

I suggest removing the third focused "behind the button" object out of the tab
order. I think it's kinda confusing to anyone tabbing through that element on
any form.

Comment 3

[James Lariviere]

Adding test case.

Changing severity to minor since this is a cleanup issue and probably will
change when moving over to the new xbl widgets.

Unsure if this is a NEW or WONTFIX or INVALID since my opinion is slanted?

Comment 4

[James Lariviere]

Attachment: input type=file tabbing testcase

Comment 5

[rods (gone)]

Chris, once the file input has focus, the first tab press take it to an area 
frame with HTMLInputElement as content, the next tab press takes it to the 
nsFileControlFrame, and the third tab press takes it to the next correct 
tabbable element.

In a nutshell, the traversal object is having problems with anonymous content.

Comment 6

[saari (gone)]

Yes, the tab traversal code definitely will get some attention real soon now.
Targeting Mozilla 1.0

Comment 7

[Vladimir Ermakov]

QA Contact Update

Comment 8

[Jesse Ruderman]

See also bug 90764, button in file upload control never appears to take focus
(and doesn't take focus onmousedown).

Comment 9

[saari (gone)]

I believe bryner has a dup of this

Comment 10

[Brian Ryner (not reading)]

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

Comment 11

[TucsonTester3]

This is a major issue and is still happening with build 2002020103, adding
keyword nsbeta1

Comment 12

[Brian Ryner (not reading)]

XBL form controls will not be turned on for 0.9.9.  -> 1.0.

Comment 13

[Aaron Leventhal]

Minusing, per ADT triage

Comment 14

[Pete Zha]

Attachment: Patch

Just skip the fileControlFrame in the GetNextTabIndexContent

Comment 15

[Pete Zha]

Attachment: Patch

Using disable bool instead of needTab

Comment 16

[Pete Zha]

Attachment: Patch

sorry for my mistake, just ignore last patch

Comment 17

[Brian Ryner (not reading)]

Comment on attachment 73497 [details] [diff] [review]
Patch

r=bryner

Comment 18

[[not reading bugmail]]

I've seen this the other day, and there was page content layed out on top of an
input box, that I tabbed into and I had no idea where I went.. dont know if it
was a mozilla layout issue, but I had to use IE to get a better rendered page,
so I could see/use that input box.

Comment 19

[Marc Attinasi]

Comment on attachment 73497 [details] [diff] [review]
Patch

sr=attinasi

Comment 20

[Asa Dotzler [:asa]]

Comment on attachment 73497 [details] [diff] [review]
Patch

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 21

[Brian Ryner (not reading)]

Checked in.

Comment 22

[Aaron Leventhal]

Does this fix it so that when a script focuses the file control, that the
textfield gets focused?

Comment 23

[Pete Zha]

arronl:Yes, see following code in nsFileControlFrame.cpp
void 
nsFileControlFrame::SetFocus(PRBool aOn, PRBool aRepaint)
{
  // Fix for Bug 6133 
  if (mTextFrame) {
    nsCOMPtr<nsIContent> content;
    mTextFrame->GetContent(getter_AddRefs(content));
    if (content) {
      content->SetFocus(mPresContext);
    }
  }
}

Comment 24

[James Lariviere]

Looking at the testcase in attachement 17693, on the second tab through the file
input I would expect the "Browse..." button to have a dotted border.

Why does the button in the file input not show focus like the submit button does?

Good job removing the 3rd tab but I think that this needs a little more polish
(winTB build 3-20-03).

Comment 25

[Pete Zha]

James, I agree with you. But I think it's another problem that layout should
paint the border for the button... Can you file another bug against this
problem? And I will take a look at it if you file it. Thanks :-)

Comment 26

[James Lariviere]

Marking as verified fixed. :-)

The button focus issue is filed under bug 132557.

Comment 27

[Pete Zha]

->myself for tracking