Running tests on focused and non-focused editable elements

Ehsan Akhgari

unread,

Jul 13, 2011, 1:58:35 PM7/13/11

to browserscope

Hi all,

Today I was debugging a patch in Firefox which was regressing a lot of
the richtext2 tests. I was trying to reduce the failure to a single
test case, but no matter what I did, I couldn't reproduce the bug in
my own testcase. After a bit of debugging, I figured out the main
difference: the bug only occurred if the editable element was not
focused. The richtext2 suite runs all of its tests without focusing
the editable elements. Seeing this behavior made me think that it
probably makes sense to repeat each test once again with the editable
element focused too, in case a bug in a browser causes the behavior in
those two cases to be different.

What do you guys think?

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>

Roland Steiner

unread,

Jul 13, 2011, 9:31:16 PM7/13/11

to browse...@googlegroups.com, Lindsey Simon, Ehsan Akhgari

It certainly seems worthwhile, and I should try to see how other browsers fare. But I'm a bit worried that we're getting into a combinatorial explosion with running every test in 3 different containers, with/without styleWithCSS and now with/without focus. There is also the (ongoing) question how to best report scores for all this. Any ideas how to tackle this (or am I worrying too much)?

Cheers,

- Roland

Ehsan Akhgari

unread,

Jul 14, 2011, 11:44:52 AM7/14/11

to Roland Steiner, browse...@googlegroups.com, Lindsey Simon

As somebody who needs to go through the list of all results and look
at many of them individually, I certainly sympathize with your
concern. :-) But honestly I think there is so much broken here that
doing any number of additional tests is definitely worth it.
Specifically, bugs that depend on the focus status will show up to web
developers as things which seemingly randomly break (since the
distinction of selection and focus is not very intuitive to many web
developers).

On how to best report the scores, it kind of depends on who the
audience is, I think. For me, the current detailed reporting is
ideal. For regular users, I'm not sure if they need anything beyond a
"X of Y tests passed" measure.

What do you think?

--
Ehsan
<http://ehsanakhgari.org/>

Roland Steiner

unread,

Jul 14, 2011, 8:46:50 PM7/14/11

to Ehsan Akhgari, browse...@googlegroups.com, Lindsey Simon

It does seem to be worth a try at least. RichText2 already only gives an abbreviated scoring, so this may not actually need to change. OTOH, the full-details result structure may change in a non-backwards-compatible way, so you guys would need to update your unit tests a bit.

Please allow me a couple of days before I can fiddle around with it, though, as I'm in the middle of a completely unrelated project ATM.

Cheers,

- Roland

Ehsan Akhgari

unread,

Jul 15, 2011, 10:24:08 AM7/15/11

to Roland Steiner, browse...@googlegroups.com, Lindsey Simon

On Thu, Jul 14, 2011 at 8:46 PM, Roland Steiner

That sounds great, I appreciate your help! :-)

And don't worry about keeping things stable, I can easily change our
unit test integration code.

--
Ehsan
<http://ehsanakhgari.org/>

Roland Steiner

unread,

Jul 20, 2011, 1:33:07 AM7/20/11

to Ehsan Akhgari, browse...@googlegroups.com, Lindsey Simon

Quick question: does this discrepancy between focused/unfocused only happen if the container is a <div>, or does it also happen when the test is run inside with <body contenteditable> or with designMode="on"?

- Roland

Ehsan Akhgari

unread,

Jul 20, 2011, 5:20:38 PM7/20/11

to Roland Steiner, browse...@googlegroups.com, Lindsey Simon

In this specific case which I noticed, it would happen in all of those modes.

--
Ehsan
<http://ehsanakhgari.org/>

Roland Steiner

unread,

Jul 22, 2011, 1:56:11 AM7/22/11

to Ehsan Akhgari, Lindsey Simon, browse...@googlegroups.com

Hi Lindsey,

I just pushed a change that implements the additional tests that Ehsan requested:

.) run every test twice, once with the editing container unfocused, once with focus

.) update the result structure to hold the additional results

.) update the output: add an additional column, output results for both unfocused and focused

.) updated unittestexample.html

Additionally:

.) moved test containers to top of page to avoid the screen jumping around while the tests are executed

.) fixed a bug where the output was incorrect when the selection escaped into the canaries (only happens in Opera, AFAICT)

.) added comments in various places

@Ehsan: please verify that the way the focus is set/removed is acceptable. The code snippet in question (in pad.js):

if (focused) {

container.editor.focus();

} else {

window.focus();

window.blur();

}

Cheers,

- Roland

Reply all

Reply to author

Forward