Selecting text in the <summary> tag activates the details/summary (opens/closes the details tag)

[gijsk]

Filed after https://bugzilla.mozilla.org/show_bug.cgi?id=1809494 was found to be a spec issue.

STR:

1. open https://jsbin.com/sehedijoga/edit?html,output or similar
2. try to select the text in the summary tag with the mouse

Expected:
when letting go of the left mouse button, the state of the details/summary tag shouldn't change

Actual:
the details/summary tag gets collapsed/expanded

The results are the same in Gecko and Blink. @smaug---- pointed out this is a result of the toggling being connected to the activation behaviour of details/summary which specify this, and the fact that a click event is still generated in the case described in the STR.

I think this is not user-friendly, and should be changed. If I was newer to the web platform I'd suggest that the click event shouldn't fire in this case. However, I expect that changing that may not be web-compatible, so I'd settle for fixing the details/summary behaviour, at least.

[zcorpan]

Compare with <label><input type=checkbox> label</label> which does not toggle the checkbox when selecting text in Firefox and Chrome, but does in Safari.

https://software.hixie.ch/utilities/js/live-dom-viewer/saved/11178

[dbaron]

an alternative is #3191, which proposes making the text in summary unselectable (also see #2272).

[gijsk]

an alternative is #3191, which proposes making the text in summary unselectable (also see #2272).

I suppose so - I would posit that it's user-hostile to prevent text selection just because the text is in a <summary>. A pretty typical usecase for summary/details would include e.g. FAQ pages with questions as summary and answers as details, and being unable to select the question portions would seem counterintuitive. Of course a site could then work-around by re-enabling user-select from CSS, but then they'd run into the problem described in this ticket again.

IMO it all boils down to detecting user intent around the two interaction possibilities of selection vs. clicking/activating. This ticket is complaining about what happens when the intent is selection and the activation is an unwanted side effect, #3191 complains about the inverse. I think having a spec change to more clearly delineate the two interactions would be better than just disabling one of the interactions altogether, even if that would indeed also resolve the ambiguity around user intent.

[zcorpan]

Maybe this should be defined in https://w3c.github.io/uievents/#event-flow-activation

[zcorpan]

cc @garykac

[dbaron]

FWIW, I probably do agree with #8707 (comment) that we should continue allowing selection, but we need to ensure that various user actions only cause one result rather than two... and make sure that it's the expected result.

[dbaron]

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1469699 on fixing this in Chromium.

[greggman]

I'm sure this is the same issue but thought I'd point it out since the behavior is different in Firefox

If there's an <input type="text"> in the summary then ending a selection outside the text area toggles the details in chrome/safari but not firefox

Screen.Recording.2023-08-21.at.11.56.03.mov