From bug 17450: > The only suggestion I think I could make is whether it would make sense to add some bits to the test to check that pressing "Tab" after moving the focus by following a link works properly. We'll do that here instead of recycling the reviewed patch.
Created attachment 198279 [details] Patch proposal Thanks for filing this bug after the other one got fixed. Now proposing a patch for this one
Adding Chris to ask for review
Comment on attachment 198279 [details] Patch proposal Attachment 198279 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/165027 New failing tests: fast/dom/fragment-activation-focuses-target.html
Created attachment 198325 [details] Archive of layout-test-results from webkit-ews-04 for mac-mountainlion The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: webkit-ews-04 Port: mac-mountainlion Platform: Mac OS X 10.8.2
Reassigning to Mario to resolve the layout test failure.
Comment on attachment 198279 [details] Patch proposal Attachment 198279 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/16133 New failing tests: fast/dom/fragment-activation-focuses-target.html
Created attachment 198666 [details] Archive of layout-test-results from webkit-ews-14 for mac-mountainlion-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: webkit-ews-14 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.2
(In reply to comment #5) > Reassigning to Mario to resolve the layout test failure. According to the diff, the problem seems to be this: Verify that the focus is on the link. PASS document.activeElement is link1 Verify Tab behaves correctly before clicking the link. -PASS document.activeElement is document.getElementById('link2') -PASS document.activeElement is document.getElementById('link1') +FAIL document.activeElement should be file:///Volumes/Data/EWS/WebKit/LayoutTests/fast/dom/fragment-activation-focuses-target.html#fragment2. Was [object HTMLDivElement]. +FAIL document.activeElement should be file:///Volumes/Data/EWS/WebKit/LayoutTests/fast/dom/fragment-activation-focuses-target.html#fragment1. Was [object HTMLBodyElement]. Click the link and verify that focus has moved to the fragment. PASS document.activeElement is document.getElementById('fragment1') ... which I guess is perhaps happening due to some objects being focusable in the Mac but not in the Gtk port (where it works fine), or maybe it's because the tab is not where I was supposing it to be after setting the focus initially on link1 and before actually clicking the link, which I'm not sure whether it would be a bug or not in the context of Mac. In any case, what seems to be working in this test, also in the mac, is that tab behaves as expected AFTER clicking the link, which is the most important thing to test here. So, perhaps the right thing to do is just to leave those checks after clicking the link here and remove the other ones, and maybe file a new bug for that strange initial situation that only seemed to happen in Mac. What do you think?
(In reply to comment #8) > (In reply to comment #5) > > Reassigning to Mario to resolve the layout test failure. > > According to the diff, the problem seems to be this: > > Verify that the focus is on the link. > PASS document.activeElement is link1 > Verify Tab behaves correctly before clicking the link. > -PASS document.activeElement is document.getElementById('link2') > -PASS document.activeElement is document.getElementById('link1') > +FAIL document.activeElement should be file:///Volumes/Data/EWS/WebKit/LayoutTests/fast/dom/fragment-activation-focuses-target.html#fragment2. Was [object HTMLDivElement]. > +FAIL document.activeElement should be file:///Volumes/Data/EWS/WebKit/LayoutTests/fast/dom/fragment-activation-focuses-target.html#fragment1. Was [object HTMLBodyElement]. > Click the link and verify that focus has moved to the fragment. > PASS document.activeElement is document.getElementById('fragment1') > > > ... which I guess is perhaps happening due to some objects being focusable in the Mac but not in the Gtk port (where it works fine), or maybe it's because the tab is not where I was supposing it to be after setting the focus initially on link1 and before actually clicking the link, which I'm not sure whether it would be a bug or not in the context of Mac. > > In any case, what seems to be working in this test, also in the mac, is that tab behaves as expected AFTER clicking the link, which is the most important thing to test here. > > So, perhaps the right thing to do is just to leave those checks after clicking the link here and remove the other ones, and maybe file a new bug for that strange initial situation that only seemed to happen in Mac. > > What do you think? That sounds fine to just update the after the click tabs. I've noticed the initial focus of the web page in layout tests is hard to nail down across platforms
Created attachment 199003 [details] Patch proposal New patch checking the tab behavior just after following the link, as per Chris's comments
Comment on attachment 199003 [details] Patch proposal Clearing flags on attachment: 199003 Committed r148882: <http://trac.webkit.org/changeset/148882>
All reviewed patches have been landed. Closing bug.