Case study: label and contenteditable

This is a run-through of one developer's approach to Test the Web Forward. It will show you ways you can be involved, some of the challenges you may face, and the reward at the end.

Scenario

<label contenteditable="true">My label</label> behaves differently in Firefox.

I discovered this when testing out an editing interface for a product at work. Searching lead me to this question on stackoverflow (Contenteditable on label tag does not work in firefox) and this bug report (Bug 853519 - contenteditable does not work properly on <label> elements).

Inconsistent behaviour is the perfect opportunity to test the web forward!

Make a plan

  1. check the web specification for LABEL and contenteditable
  2. check browser behaviour
  3. review existing tests in Test the Web Forward
  4. write a new test
  5. determine where to add the test
  6. submit the test

Check the spec

I started with reading up on both the label element and the contenteditable attribute. This was difficult. The spec is vague about the "activation behaviour" of labels (because it is different for text fields and checkboxes, and might be platform dependent), and the editing API is in draft and doesn't talk too specifically about what happens when you click (or activate) an editable element.

I didn't come out of this with a clear understanding of what should happen. I'm going to create a test case and check more browsers.

Learnings

References

Check browser behaviour

I created a quick demo page and refactored it after discussion with James Graham.

See the Pen label@contenteditable tests by Ben Boyle (@bboyle) on CodePen.

Initially I did not see any difference in behaviour in Firefox and Chrome (which was what I originally set out to test for!) It appears that a single click on the label puts the focus on the associated text field in both browsers. A click-and-drag action selects text in the label and it can then be edited. Likewise, it is possible to Tab between the label and input control.

In IE11 and Edge however, a single-click keeps the focus on the label element.

That isn't the bug I was looking for, but it's still an inconsistency and worth adding a test for. Unfortunately it's difficult to add a test for behaviour that isn't detailed in the specifications!

Exploring unspecified behaviour

James had very helpful comments:

I think possibly this should be regarded as a spec bug though and Firefox and Chrome should change because I think the spec should consider the case where the label is itself editable and forbid activation behaviour, just like it does for <label for=foo><button></label><input id=foo>

it's worth noting that accompanying a spec bug report with a reduced test case like this is very strongly encouraged because it makes the bug report much more precise and easy to understand. So in no sense should you "not write the test"; it's just that when you come to get the test reviewed (or review it yourself) it might turn out that you have to take a slightly different course of action than normal.

This led to expanding the test on codepen. I wanted to explore if this inconsistent behaviour could be narrowed down. To do this, I think about different "states" a label could be in. Here, it is the combination of contenteditable and for attributes that are interesting. I came up with these extra contexts:

Note that these new labels are not appropriate if you are writing valid, interoperable HTML. The point here is to test behaviour in the browsers—including how they behave with unusual or invalid HTML. We're not testing valid HTML, that's what HTML validators are for.

There were consistent results across most browsers with this. Chrome, IE11 and Edge all agreed that the extra labels would keep focus, which left the original test as the single failure. I feel like I've started to isolate the interoperability issue. Unfortunately I found a new isue: every test failed in Firefox. What? That is explored in Case study: focus() and label in Firefox.

DRAFT: to be continued…

Learnings