1610081 - The non-scrolling sidebar in about:addons and about:preferences is a potential migraine trigger

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect, P3)

Description

[MarjaE]

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

Steps to reproduce:

Used about:addons

Actual results:

It has a sidebar which does no scroll with the rest of the page.

It's not as bad as most pages with this layout, but it's still a potential migraine trigger and/or aggravator.

Right now, the non-scrolling sidebar and scrolling add-on list are next to each other on the left side of the window. Maybe it would work better if they were on opposite sides of the window, space permitting.

Comment 1

[MarjaE]

Related: Bug 1505924

I don't think this is a regression.

Comment 2

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Mark Striemer [:mstriemer]]

Do you feel the same way about the about:preferences page which has this behaviour? What would be a solution to this? Making it more obvious that the sidebar doesn't scroll or something else?

Comment 4

[MarjaE]

Yes.

For me, the ideal solution would have it scroll with the rest of the page. If that's not an option, either moving it into the top bar, without sticky-header-style animation, or moving it to the far side, so there's as much space as possible between the scrolling and non-scrolling text.

Comment 5

[MarjaE]

Also a vertical line or color switch might help a bit. I find more contrast helps reduce pain when elements sheer alongside each other, while less may help when elements slide under another.

Comment 6

[Mark Striemer [:mstriemer]]

@Asa, This is a pattern we use on a few in-content pages where the sidebar is fixed and the main content scroll but there's nothing differentiating between the scrollable and non-scrollable areas. Is this something the a11y team would perhaps look at improving across these pages?

Comment 7

[Asa Dotzler [:asa]]

I've been scouring the web and other applications and this pattern, a left side fixed position sidebar and right side scrolling content area, is very very common to web sites and apps. The only significant difference I see between our implementation and many others is that we do not have a visual separation between the sidebar and the content area, either a vertical rule or a color change. It's unclear to me, however, if such a visual separation would actually improve things significantly for this reporter, and as importantly, the larger population of people who may be negatively affected by the design. "Might help a bit" for one or even some users doesn't seem like the kind of impact that would necessarily support such a change.

Comment 8

[Asa Dotzler [:asa]]

Adding the access keyword and the access-p2 whiteboard flag because the feature can be used but with some difficulty or negative consequences. Perhaps UX could come up with a design that doesn't have a fixed position sidebar or which more clearly visually separates the sidebar from the content area. We don't have visual designers on the accessibility engineering team so we're unlikely to tackle this.

Comment 9

[Shane Caraveo (:mixedpuppy)]

Because this is a general UI approach in firefox (not just about:addons) I'm moving it over to the firefox team to triage and decide whether this pattern should be changed somehow.

Comment 10

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Clara

Comment 11

[Asa Dotzler [:asa]]

Updating the Accessibility Team's impact assessment to conform with the new triage guidelines. See https://wiki.mozilla.org/Accessibility/Triage for descriptions of these whiteboard flags.

Comment 12

[Jared Wein [:jaws] (please needinfo? me)]

The issue here is the animation and the fixed positioning on the sidebar. Firefox respects the reduced motion preferences of users, and users who suffer from animation-induced migraines likely will need reduced-motion enabled to use Firefox (and other apps). We can use this reduced-motion preference to put a border on the side of the navigation menu so as to put a clear differentiation between the navigation and the main content area.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d53a34d54588
Show a border between the sidebar and the content area in about:addons and about:preferences when prefers-reduced-motion is enabled to help users with visual tearing migraines. r=Gijs

Comment 14

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 1610081 - Show a border between the sidebar and the content area in about:addons and about:preferences when prefers-reduced-motion is enabled to help users with visual tearing migraines. r?gijs

Comment 15

[Dorel Luca [:dluca]]

Backed out changeset d53a34d54588 (bug 1610081) for Browser-chrome in test/browser/browser_sidebar_categories.js. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=302312179&repo=autoland&lineNumber=4540

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=d53a34d54588e2c330d0760699a3bdf69fb6aa61

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

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1a271e4d8937
Show a border between the sidebar and the content area in about:addons and about:preferences when prefers-reduced-motion is enabled to help users with visual tearing migraines. r=Gijs

Comment 17

[Cristina Coroiu [:ccoroiu]]

Backed out changeset 1a271e4d8937 (bug 1610081) for assertion failures at layout/base/nsCSSFrameConstructor.cpp

Backout: https://hg.mozilla.org/integration/autoland/rev/5313db6cbb8abe60b65e9d8928db585ba1b5f63e

Failure push: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=1a271e4d89373b482df85adc17c094b5275453b4

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=302332121&repo=autoland&lineNumber=5208

task 2020-05-14T19:59:17.921Z] 19:59:17 INFO - TEST-START | browser/components/extensions/test/browser/browser_ext_contentscript_in_parent.js
[task 2020-05-14T19:59:17.941Z] 19:59:17 INFO - GECKO(1230) | [Parent 1230: Main Thread]: I/DocShellAndDOMWindowLeak ++DOCSHELL 0x7f5f39a46800 == 16 [pid = 1230] [id = {6d22f3a8-7737-426c-bb9b-4060c53f393c}]
[task 2020-05-14T19:59:17.942Z] 19:59:17 INFO - GECKO(1230) | [Parent 1230: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 60 (0x7f5f4050b820) [pid = 1230] [serial = 116] [outer = (nil)]
[task 2020-05-14T19:59:17.943Z] 19:59:17 INFO - GECKO(1230) | [Parent 1230: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 61 (0x7f5f39a4d000) [pid = 1230] [serial = 117] [outer = 0x7f5f4050b820]
[task 2020-05-14T19:59:18.059Z] 19:59:18 INFO - GECKO(1230) | [Parent 1230, Main Thread] WARNING: NS_ENSURE_TRUE(rootFrame) failed: file /builds/worker/checkouts/gecko/dom/base/nsGlobalWindowOuter.cpp, line 4265
[task 2020-05-14T19:59:18.067Z] 19:59:18 INFO - GECKO(1230) | [Parent 1230: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 62 (0x7f5f39d9dc00) [pid = 1230] [serial = 118] [outer = 0x7f5f4050b820]
[task 2020-05-14T19:59:18.929Z] 19:59:18 INFO - GECKO(1230) | [Parent 1230, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file /builds/worker/checkouts/gecko/dom/base/nsContentUtils.cpp, line 3734
[task 2020-05-14T19:59:18.930Z] 19:59:18 INFO - GECKO(1230) | Assertion failure: !disp->IsAbsolutelyPositionedStyle() || disp->DisplayInside() != StyleDisplayInside::MozBox (This may be a frame that was previously blockified but isn't any longer! It probably needs explicit 'display:block' to preserve behavior), at /builds/worker/checkouts/gecko/layout/base/nsCSSFrameConstructor.cpp:5585
[task 2020-05-14T19:59:18.930Z] 19:59:18 INFO - GECKO(1230) | #01: nsCSSFrameConstructor::ConstructFramesFromItemList(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList&, nsContainerFrame*, bool, nsFrameList&) [layout/base/nsCSSFrameConstructor.cpp:9445]
[task 2020-05-14T19:59:18.931Z] 19:59:18 INFO - GECKO(1230) | #02: nsCSSFrameConstructor::ProcessChildren(nsFrameConstructorState&, nsIContent*, mozilla::ComputedStyle*, nsContainerFrame*, bool, nsFrameList&, bool, nsIFrame*) [layout/base/nsCSSFrameConstructor.cpp:9629]
[task 2020-05-14T19:59:18.931Z] 19:59:18 INFO - GECKO(1230) | #03: nsCSSFrameConstructor::ConstructFrameFromItemInternal(nsCSSFrameConstructor::FrameConstructionItem&, nsFrameConstructorState&, nsContainerFrame*, nsFrameList&) [layout/base/nsCSSFrameConstructor.cpp:3723]
[task 2020-05-14T19:59:18.934Z] 19:59:18 INFO - GECKO(1230) | #04: nsCSSFrameConstructor::ConstructFramesFromItem(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList::Iterator&, nsContainerFrame*, nsFrameList&) [layout/base/nsCSSFrameConstructor.cpp:5627]
[task 2020-05-14T19:59:18.934Z] 19:59:18 INFO - GECKO(1230) | #05: nsCSSFrameConstructor::ConstructFramesFromItemList(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList&, nsContainerFrame*, bool, nsFrameList&) [layout/base/nsCSSFrameConstructor.cpp:9445]
[task 2020-05-14T19:59:18.935Z] 19:59:18 INFO - GECKO(1230) | #06: nsCSSFrameConstructor::ProcessChildren(nsFrameConstructorState&, nsIContent*, mozilla::ComputedStyle*, nsContainerFrame*, bool, nsFrameList&, bool, nsIFrame*) [layout/base/nsCSSFrameConstructor.cpp:9629]
[task 2020-05-14T19:59:18.938Z] 19:59:18 INFO - GECKO(1230) | #07: nsCSSFrameConstructor::ConstructFrameFromItemInternal(nsCSSFrameConstructor::FrameConstructionItem&, nsFrameConstructorState&, nsContainerFrame*, nsFrameList&) [layout/base/nsCSSFrameConstructor.cpp:3723]
[task 2020-05-14T19:59:18.939Z] 19:59:18 INFO - GECKO(1230) | #08: nsCSSFrameConstructor::ConstructFramesFromItem(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList::Iterator&, nsContainerFrame*, nsFrameList&) [layout/base/nsCSSFrameConstructor.cpp:5627]
[task 2020-05-14T19:59:18.940Z] 19:59:18 INFO - GECKO(1230) | #09: nsCSSFrameConstructor::ConstructFramesFromItemList(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList&, nsContainerFrame*, bool, nsFrameList&) [layout/base/nsCSSFrameConstructor.cpp:9445]
[task 2020-05-14T19:59:18.943Z] 19:59:18 INFO - GECKO(1230) | #10: nsCSSFrameConstructor::ProcessChildren(nsFrameConstructorState&, nsIContent*, mozilla::ComputedStyle*, nsContainerFrame*, bool, nsFrameList&, bool, nsIFrame*) [layout/base/nsCSSFrameConstructor.cpp:9629]
[task 2020-05-14T19:59:18.944Z] 19:59:18 INFO - GECKO(1230) | #11: nsCSSFrameConstructor::ConstructFrameFromItemInternal(nsCSSFrameConstructor::FrameConstructionItem&, nsFrameConstructorState&, nsContainerFrame*, nsFrameList&) [layout/base/nsCSSFrameConstructor.cpp:3723]
[task 2020-05-14T19:59:18.945Z] 19:59:18 INFO - GECKO(1230) | #12: nsCSSFrameConstructor::ConstructFramesFromItem(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList::Iterator&, nsContainerFrame*, nsFrameList&) [layout/base/nsCSSFrameConstructor.cpp:5627]
[task 2020-05-14T19:59:18.949Z] 19:59:18 INFO - GECKO(1230) | #13: nsCSSFrameConstructor::ConstructFramesFromItemList(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList&, nsContainerFrame*, bool, nsFrameList&) [layout/base/nsCSSFrameConstructor.cpp:9445]
[task 2020-05-14T19:59:18.949Z] 19:59:18 INFO - GECKO(1230) | #14: nsCSSFrameConstructor::ProcessChildren(nsFrameConstructorState&, nsIContent*, mozilla::ComputedStyle*, nsContainerFrame*, bool, nsFrameList&, bool, nsIFrame*) [layout/base/nsCSSFrameConstructor.cpp:9629]
[task 2020-05-14T19:59:18.951Z] 19:59:18 INFO - GECKO(1230) | #15: nsCSSFrameConstructor::ConstructBlock(nsFrameConstructorState&, nsIContent*, nsContainerFrame*, nsContainerFrame*, mozilla::ComputedStyle*, nsContainerFrame**, nsFrameList&, nsIFrame*) [layout/base/nsCSSFrameConstructor.cpp:10505]
[task 2020-05-14T19:59:18.951Z] 19:59:18 INFO - GECKO(1230) | #16: nsCSSFrameConstructor::ConstructDocElementFrame(mozilla::dom::Element*) [layout/base/nsCSSFrameConstructor.cpp:2346]
[task 2020-05-14T19:59:18.952Z] 19:59:18 INFO - GECKO(1230) | #17: nsCSSFrameConstructor::ContentRangeInserted(nsIContent*, nsIContent*, nsCSSFrameConstructor::InsertionKind) [layout/base/nsCSSFrameConstructor.cpp:6959]
[task 2020-05-14T19:59:18.956Z] 19:59:18 INFO - GECKO(1230) | #18: mozilla::PresShell::Initialize() [layout/base/PresShell.cpp:1840]

Comment 18

[Jared Wein [:jaws] (please needinfo? me)]

Emilio, do you know why this is hitting this assertion?

Comment 19

[Emilio Cobos Álvarez (:emilio)]

position: absolute / position: fixed is not supposed to be used with display: -moz-box. Use display: block instead. See bug 1582819 which introduced these assertions (display: -moz-box used to get blockified to block before).

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bfb47f89a941
Show a border between the sidebar and the content area in about:addons and about:preferences when prefers-reduced-motion is enabled to help users with visual tearing migraines. r=Gijs

Comment 21

[Atila Butkovits]

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

Comment 22

[Cristian Fogel [:cfogel]]

Confirmed the issue with 72.0 on macOS 10.15.5.
Fix verified with 78.0b6.

Comment 24

[MarjaE]

Attachment: Not fixed as of Firefox 79

Still not fixed as of Firefox 79. (1) the main scrolling section is jammed up against the non-scrolling sidebar, though there's plenty of space on the other side, and (2) the edge lacks any separator. Using own userChrome.css, thus the appearance.

Comment 25

[MarjaE]

Not fixed in 79.

Comment 26

[MarjaE]

Checking mozregression, the default versions (2) have a separator, but (1) still don't have any distance between the scrolling section and the non-scrolling sidebar.

Comment 27

[Mathew Hodson]

(In reply to MarjaE from comment #26)

Checking mozregression, the default versions (2) have a separator, but (1) still don't have any distance between the scrolling section and the non-scrolling sidebar.

Since this bug was closed when the separator was added in Firefox 78, you should open a new bug for creating more space between the content and the sidebar.

Otherwise, it's not going to be tracked properly.