83394 - Tabindex attribute not working properly in mfcembed app

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect, P2)

Description

[Christine Hoffman]

Tested on Win98 5/25/09 mfcembed application.

Seven HTML elements have a 'tabindex' attribute: A, AREA, BUTTON, INPUT, OBJECT, 
SELECT, TEXTAREA.

Expected results: Tabbing order should occur as indicated
Actual results: In 'mfcembed', tabbing does nothing until you click in the 
window to get focus. Then, the tabbing does not go to the first order - its 
starts with the second. In Netscape, clicking first is not necessary and tabbing 
order is complete.

URL above contains testcases for all applicable elements. Since that directory 
is internal, I will attach one testcase for external use.

Comment 1

[Christine Hoffman]

Reassigning to [e-mail] changing qa contact to chrisd

Comment 2

[Christine Hoffman]

Attachment: testcase to demonstrate problem

Comment 3

[Christine Hoffman]

If the component is not appropriate, please change.

Comment 4

[saari (gone)]

jgaunt, is this fixed now with initial focus?

Comment 5

[John Gaunt (redfive)]

Nope, not only are tabindexes still out of order, tabbing is all horked. I can't
initially tab into a page's tab order. if there isn't a text input or something
I can click on to start the progression I get bubkis, nada, zip. Oh, and
shift-tab doesn't work either. ;-) If I get to the end of the tab order I'm
stuck, it doesn't want to cycle around like in mozilla.

In mozilla, I get the wacky order, but at least I get right into it.

Comment 6

[Christine Hoffman]

When I tested with the 'Netscape' app (5/24/09 build), the tabbing order worked 
correctly with the testcases provided. The only problem I have is with the 
'mfcembed' app. John, what 'wacky' order are you seeing in Mozilla?

Comment 7

[John Gaunt (redfive)]

the 'wacky' order follows what you represent on those pages by labeling the
links "this is link 1 but number 3 in tab order" in that kind of fashion.

Comment 8

[Peter Trudelle]

->jag

Comment 9

[Peter Trudelle]

->0.9.2

Comment 10

[jag (Peter Annema)]

Per hyatt, since the urlbar is a menulist, tab will select the text in it.
Default Windows behaviour, nothing you can change about it unless you use a
different widget.

Still trying to find out what's going on w.r.t. to tab going out of the document
and never coming back.

Comment 11

[jag (Peter Annema)]

So, when you tab out of textfield 3, the whole document is selected. This works
fine.

The next tab then asks the embedding app. to focus the next item. This is so
that the embedder can decide whether to focus their chrome, the urlbar, some
other widget, or just move it back to the top of the document. For mfcEmbed,
this isn't implemented. I've verified though that it works as designed I could
add a printf at that place if you need some feedback that it indeed works.

That leaves us with two issues:
1) clicking the content area, the first tab doesn't take you to the second
indexed widget, instead of the first.

2) shift-tab doesn't (seem to) work for indexed widgets.

These two bugs show in both mfcEmbed and the mozilla browser itself.
I'll file a new bug on the second issue (if there isn't one already) and will
use this bug to address issue 1.

Comment 12

[jag (Peter Annema)]

Issue 2 is bug 67404.

Comment 13

[jag (Peter Annema)]

bryner fixed most of issue #1 a few days ago. There is a special case where
clicking in the content directly on the body element, you still go to the second
indexed element instead of the first. Bryner has a patch for that.

Comment 14

[Brian Ryner (not reading)]

Attachment: patch

Comment 15

[jag (Peter Annema)]

r=jag

Comment 16

[David Hyatt]

sr=hyatt

Comment 17

[chris hofmann]

a=chofmann

Comment 18

[chris hofmann]

be good if we could get this on trunk and branch before monday morning if we can.

Comment 19

[jag (Peter Annema)]

Sorry, checked in last night, marking fixed.

Comment 20

[Christine Hoffman]

Tested using 06_26_18_0.9.2 'mfcembed' build on Win98. Tested the 'tabindex' 
attribute with the following elements: 
A, AREA (using image and using object), BUTTON, INPUT, OBJECT, SELECT, TEXTAREA

Tabindex is fixed on all of these elements except the AREA element (when using 
object) and the OBJECT element. These problems are already written up as bug 
#72870 (AREA used with object) and #88140 (AREA).

Verifying this bug fixed in 'mfcembed' - now works like Netscape build.