Closed Bug 1470229 Opened 6 years ago Closed 6 years ago

Reader mode strips aria-label

Categories

(Toolkit :: Reader Mode, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla63
Tracking Status
firefox63 --- verified

People

(Reporter: eeejay, Assigned: xidorn)

Details

Attachments

(2 files)

STR:

1. Load https://s.codepen.io/joe-watkins/debug/gKWJva
2. Observe that the first "Read Next" link has an aria-label attribute.
3. Toggle reader mode
4. Observe the the fist "Read Next" link is missing it's aria-label

We should preserve all 'role' and 'aria-*' attributes. Some attributes that define relations like aria-labelledby with ids that were stripped will be broken. I wouldn't worry about it, and leave it to our a11y engine to try and fail to resolve those.
Looks like this is done in nsTreeSanitizer via nsIParserUtils. 'role' seems to be fine.

Should we create a new flag about preserving aria attributes, or should they really be part of the default HTML attributes corpus defined here:
https://searchfox.org/mozilla-central/rev/d0a41d2e7770fc00df7844d5f840067cc35ba26f/dom/base/nsTreeSanitizer.cpp#151

Flagging xidorn because I don't know who to ask!
Flags: needinfo?(xidorn+moz)
I have some idea about how to fix it. Keep the ni? for now.
Assignee: nobody → xidorn+moz
Flags: needinfo?(xidorn+moz)
Comment on attachment 8986975 [details]
Bug 1470229 part 1 - Make the starting-with check in nsTreeSanitizer::SanitizeAttributes nicer.

https://reviewboard.mozilla.org/r/252226/#review259098
Attachment #8986975 - Flags: review?(hsivonen) → review+
Pushed by xquan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/06abfbc384f3
part 1 - Make the starting-with check in nsTreeSanitizer::SanitizeAttributes nicer. r=hsivonen
https://hg.mozilla.org/integration/autoland/rev/e17505b46d02
part 2 - Allow aria attributes. r=hsivonen
Priority: -- → P1
https://hg.mozilla.org/mozilla-central/rev/06abfbc384f3
https://hg.mozilla.org/mozilla-central/rev/e17505b46d02
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Flags: qe-verify+
I have managed to reproduce this issue on an affected Firefox 62.0b2 (20180621152331) build using Windows 10 x64  by following the STR from comment 0. 

This issue is verified fixed using Firefox 63.0b7 (20180917143811) on the following OSes: Windows 10 x64, Ubuntu 18.04 x64, Windows 7 x64, macOS 10.13.6.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.