520004 - Fennec - mochitest chrome failure - test_focus.xul

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Doug Turner (:dougt)]

324 failures on dom/tests/mochitest/chrome/test_focus.xul.

The cause for these failures is that Fennec has a different content.css that is applied to all webpages which alters their view.  For example, we do not display scrollboxes.  This does change the focus ordering (things are rendered in different locations).

mfinkle took a screen shot of the differences:

http://people.mozilla.org/~mfinkle/fennec/screenshots/fennec-child-focus-frame.png

If you remove http://mxr.mozilla.org/mobile-browser/source/chrome/content/content.css from the build, these focus test pass.  (however, some frameset tests continue to fail probably from a similar incompatibility).

We can stop running test_focus (because they are built for firefox desktop) and create our own, or remove our custom content.css when running these tests.

Comment 1

[Doug Turner (:dougt)]

joel, what do you want to do here?

Comment 2

[Joel Maher ( :jmaher ) (UTC -8)]

is there a chance that a normal website out there will have similar css and fail?  If there is no chance of a real website hitting this, then we should find a way to move this case to browser-chrome for firefox.  

Is there a need to add a similar set of tests for Fennec?  If so we should file a bug to implement some browser-chrome tests.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

after looking at this more there are a lot of tests in this specific test file.  We should really look into:

1) splitting this out into multiple tests
2) keep the tests that work
3) rewrite fennec specific tests
4) remove the failing tests that don't work in fennec

Maybe Neil can shed some light on the best way to split this into multiple tests.

Comment 4

[Neil Deakin]

> Maybe Neil can shed some light on the best way to split this into multiple
> tests.

You don't.

The only thing I can see in the css file that would affect focus is the binding attached to <select>. Does it work if you just remove that part?

Other tests may fail as they open windows.

Is there a log of the failures available? Skipping over the <select> should be very easy.

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

I have uploaded a log file to:

http://people.mozilla.com/~jmaher/chrome_focus.log


I am not sure how to remove the select stuff.  Could that be the code in the content.css?

Comment 6

[Neil Deakin]

The log shows a number of issues, some of which are likely actual bugs:

- one should be able to tab into a scrollable area and then use the arrow keys to scroll it. This doesn't work because no scrollbars are visible and thus it is believed the user cannot scroll it.
- access keys on <select> elements don't seem to work
- some issue with tabbing in frames when reaching the end of the tab order
- a couple of issues when switching focus between documents
- focusing a textfield with the mouse doesn't seem to unselect and set the cursor position
 
I didn't test any of this, this is just from looking at the log.

Comment 7

[Joel Maher ( :jmaher ) (UTC -8)]

Neil, thanks for taking a look at this.  Dougt, any idea why the content.css would cause these issues?  Is this something we can work on fixing in separate bugs (testcase, fennec, focus)?

- access keys on <select> elements don't seem to work
probably due to our special handling of <select> elements

- some issue with tabbing in frames when reaching the end of the tab order
we do special handing of frames for panning/scrolling

- focusing a textfield with the mouse doesn't seem to unselect and set the
cursor position
we really don't have a cursor, could that be part of the problem?

Comment 8

[BMO Automation]

Closing all opened bug in a graveyard component