Closed Bug 1088467 Opened 6 years ago Closed 6 years ago

Space exposed at start of li element when CSS list-style is none

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
firefox33 --- wontfix
firefox34 --- fixed
firefox35 --- fixed
firefox36 --- fixed

People

(Reporter: Jamie, Assigned: xidorn)

References

Details

(Keywords: regression)

Attachments

(1 file)

Str:
1. Open the following URL: data:text/html,<ul><li style="list-style: none;">test</li></ul>
2. Examine the text for the list item accessible.
Expected: "test"
Actual: " test"

It makes sense that a space should be exposed after the prefix (e.g. bullet) if there is one (which wasn't the case before Firefox 32). However, if there is no prefix, a space shouldn't be exposed. This worked as expected in Firefox 32 (no space if no prefix), but regressed in Firefox 33.

This is causing spurious blank lines to appear in NVDA browse mode with screen layout disabled.
Related NVDA issue ticket: http://community.nvda-project.org/ticket/4568
Most likely a regression from bug 1013160. xidorn, could you take a look, please?
Blocks: 1013160
Flags: needinfo?(quanxunzhen)
Assignee: nobody → quanxunzhen
Status: NEW → ASSIGNED
Flags: needinfo?(quanxunzhen)
OS: Windows 8.1 → All
Hardware: x86_64 → All
Version: 33 Branch → Trunk
Attached patch patchSplinter Review
Attachment #8510878 - Flags: review?(surkov.alexander)
Attachment #8510878 - Flags: review?(jfkthame)
Attachment #8510878 - Flags: review?(jfkthame) → review+
Comment on attachment 8510878 [details] [diff] [review]
patch

Stealing review from Surkov. I ran with this patch and can confirm the fix. Also ran the a11y test suite and it passes. Thanks for this quick patch!
Attachment #8510878 - Flags: review?(surkov.alexander) → review+
BTW, should we uplift this patch?
Flags: needinfo?(mzehe)
Keywords: checkin-needed
(In reply to Xidorn Quan [:xidorn] (UTC+11) from comment #4)
> BTW, should we uplift this patch?

We can try, at least for Aurora, so the fix gets in the hands of end users sooner. I am not sure what the policy is for beta, since this will have been broken in two consecutive releases (32 and 33). But you can request approval anyway. I've set the Affected flags accordingly.
Flags: needinfo?(mzehe)
(In reply to Marco Zehe (:MarcoZ) from comment #6)
> (In reply to Xidorn Quan [:xidorn] (UTC+11) from comment #4)
> > BTW, should we uplift this patch?
> 
> We can try, at least for Aurora, so the fix gets in the hands of end users
> sooner. I am not sure what the policy is for beta, since this will have been
> broken in two consecutive releases (32 and 33). But you can request approval
> anyway. I've set the Affected flags accordingly.

Actually, I think it is a regression of bug 966166, not of bug 1013160. Hence it doesn't affect 32.
It works as expected in Firefox 32.
OK, so the flags are correct above. Yeah, request approval for Aurora and beta once this lands on m-c and we'll see where it goes.
Blocks: 966166
No longer blocks: 1013160
https://hg.mozilla.org/mozilla-central/rev/c72e16da125b
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Comment on attachment 8510878 [details] [diff] [review]
patch

Approval Request Comment
[Feature/regressing bug #]: bug 966166
[User impact if declined]: As described in comment 0
[Describe test coverage new/current, TBPL]: Add one test in mochitest a11y
[Risks and why]: no risk AFAIK
[String/UUID change made/needed]:
Attachment #8510878 - Flags: approval-mozilla-beta?
Attachment #8510878 - Flags: approval-mozilla-aurora?
Comment on attachment 8510878 [details] [diff] [review]
patch

Beta+
Aurora+
Attachment #8510878 - Flags: approval-mozilla-beta?
Attachment #8510878 - Flags: approval-mozilla-beta+
Attachment #8510878 - Flags: approval-mozilla-aurora?
Attachment #8510878 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.