1871424 - A possible reoccurrence of Bug 62151: Checkboxes in <a> element cannot be checked or unchecked - v119-v121

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[krcowles29]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:121.0) Gecko/20100101 Firefox/121.0

Steps to reproduce:

Enter a website where a photo gallery is displayed containing images grouped with checkbox alternatives. The checkboxes are within <a> elements. I set up a test case for bugzilla developers at https://nmhikes.com/bug. You must be a member to get to the described issue, so a temporary user 'bugzilla' has been created with password 'Bugzilla1$'. Select 'Members->Login' and use the previous info to login. Security questions are answered by entering 'bugzilla'. Once logged in, select 'Contribute->Continue Editing Your Page'. Next, click 'Alamo Vista' under 'Hike/Trail Name'. This will take you to the editor. Click on the tab labeled 'Photo Selection' to see the problem photo gallery - you may have to scroll down to see the photos. None of the checkboxes can be checked or unchecked. Other browsers (Chrome, Safari, Brave) do not have this issue. My user agent is Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:121.0) Gecko/20100101 Firefox/121.0 I believe the issue started with v119 and continues to be present in v120 and v121. It worked as expected prior to that time. Note: I have redesigned the code to remove the <a> parent for the checkboxes in a test case, and the checkboxes work as expected. Hence the belief that the issue is a reoccurrence of Bug 62151.

Actual results:

No checkbox can be altered (either unchecked or checked)

Expected results:

Checkboxes should behave as expected: checking a box should enter a checkmark or remove it if already present.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Robert Longson [:longsonr]]

Could you use mozregression to find a regression range?

Comment 3

[krcowles29]

(In reply to Robert Longson [:longsonr] from comment #2)

Could you use mozregression to find a regression range?

I will investigate that. I have not used mozregression before, so there may be a learning curve. Thanks for your patience.

Comment 4

[krcowles29]

I downloaded the 118.0 release, and the bug was not present. I then used the mozregression gui, specifying known dates for good and bad. The good date was set at 9-25-2023 (11:44), the date appearing next to the download dir for 118.0 for mac/en-US. The bad date was set at 11-06-2023 (22:21), the date appearing on the download dir for 119.0.1. Regression proceeded back from 11-06-2023 to commit #88f80ffa, which commit still showed the bug. I don't know the commit on the 118 release, but assume you can find that. Is this sufficient info for you to proceed?

Comment 5

[Robert Longson [:longsonr]]

You should get a regression range that looks something like this...

Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=636498d041b5&tochange=2a193b7f395c

Comment 6

[krcowles29]

Copy. I'm not familiar yet with mozregression gui, but it appears that the pushlog url is
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=042e4bc9aa5ad9f3477ceb06ded31b642e526b25&tochange=925231a8fb5eccf055afb3e9921596d8f990128b
That was in the Build Info window, along with: repo_name: mozilla-central

Comment 7

[Andreas Farre [:farre]]

Thank you so much for the report, and an extra thanks for setting up the test page. I'm able to reproduce, and I'm running mozregression as we speak. Regression range incoming.

Comment 8

[Andreas Farre [:farre]]

Vincent, Edgar: Is this something worthy of a back out?

Comment 9

[Edgar Chen [:edgar]]

This is a bit bad, investigating ...

Comment 10

[Edgar Chen [:edgar]]

(In reply to Andreas Farre [:farre] from comment #8)

Vincent, Edgar: Is this something worthy of a back out?

Bug 1658996 is shipped in 119 and I don't see other bug reports, maybe there is not many pages putting a checkbox under <a>?
Backing out bug 1658996 is a bit risky as there is other bug also depending it.
I prefer we fix this case and request uplift.

Comment 11

[Vincent Hilla [:vhilla]]

The pending patches in Bug 1851970 might fix this. There is a testcase in Event-dispatch-single-activation-behavior.html for putting a checkbox under <a> that is fixed in Bug 1851970. Landing is currently blocked by the spec issue.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1658996

Comment 13

[Edgar Chen [:edgar]]

Attachment: Bug 1871424 - Make input checkbox/radio in link element work again; r?vhilla,#dom-core

The root cause of issue is that the link elements have not yet adopted the
activation behavior defined in the specification. This patch add a hacky way to
avoid link elements perform activation behavior if it has a child input element
which will perform activation behavior. This patch introduces new flags instead of
reusing the exiting ones, allowing us to uplift this patch more safely.

Comment 14

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/jobs?repo=try&revision=925a977011de56cd38852451d6367cc41a207292

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5431daa798c7
Make input checkbox/radio in link element work again; r=vhilla,dom-core

Comment 17

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/5431daa798c7

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:edgar, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox122 to wontfix.

For more information, please visit BugBot documentation.

Comment 19

[Edgar Chen [:edgar]]

Attachment: Bug 1871424 - Make input checkbox/radio in link element work again;

The root cause of issue is that the link elements have not yet adopted the
activation behavior defined in the specification. This patch add a hacky way to
avoid link elements perform activation behavior if it has a child input element
which will perform activation behavior. This patch introduces new flags instead of
reusing the exiting ones, allowing us to uplift this patch more safely.

Original Revision: https://phabricator.services.mozilla.com/D197393

Comment 20

[Phabricator Automation]

Uplift Approval Request

• User impact if declined: input checkbox/radio doesn't work if it has a link element with href attribute
• String changes made/needed: None
• Needs manual QE test: no
• Is Android affected?: yes
• Explanation of risk level: This patch tries to minimize changes to fix the regression. It should only affect the activation behavor for the input element that has a link parent
• Code covered by automated testing: yes
• Risk associated with taking this patch: Low
• Fix verified in Nightly: yes
• Steps to reproduce for manual QE testing: None

Comment 21

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/50a511fceab9

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Let's let this ride the 122 train to release (shipping 23-Jan). For people interested in testing this fix out now, it's available in current Nightly, Beta, and Developer Edition builds.

Comment 23

[Donal Meehan [:dmeehan]]

Backed out of beta for causing Bug 1873472
https://hg.mozilla.org/releases/mozilla-beta/rev/757be60a201152744de5eee2a943d2605b1c77a4

Comment 24

[Narcis Beleuzu [:NarcisB]]

Backed out for causing Bug 1873472

Backout link: https://hg.mozilla.org/integration/autoland/rev/1f9ca9d06a6b4d508851e37c0f3695d61134ab97

Comment 25

[Cristian Tuns]

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/1f9ca9d06a6b

Comment 26

[Edgar Chen [:edgar]]

:saschanaz, I can not access bug 1874297, can you cc me there? Thanks!

Comment 27

[Kagami Rosylight [:saschanaz] (they/them)]

Done 👍

Comment 28

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/jobs?repo=try&revision=f411438bc3dfc5f281baf02357fc847d280a1798

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ae7ff06eabe7
Make input checkbox/radio in link element work again; r=vhilla,dom-core,smaug

Comment 30

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/ae7ff06eabe7