Reader View now contains a non-scrolling popup!
Categories
(Toolkit :: Reader Mode, defect)
Tracking
()
People
(Reporter: erwinm, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
3.96 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:79.0) Gecko/20100101 Firefox/79.0
Steps to reproduce:
I tried to read an article in Reader View.
Actual results:
It now has a non-scrolling popup.
I tried to close the popup.
I got knocked back out of Reader View.
Expected results:
Reader View should be as readable as possible. It should not contain non-scrolling elements alongside scrolling ones.
Comment 1•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
The old design felt better, probably because (a) it had more distance between the scrolling and non-scrolling elements, and (b) it had a vertical line separating them.
The intermediate design also felt better.
Mozregression freezes on build 300f8613.
The new design was introduced here: https://hg.mozilla.org/mozilla-central/rev/3017e4a904482f1f33b08d268441b42590db4ef5
To resolve bug 1637652.
I don't have any semi-transparent elements either way, can't handle popups either.
Updated•4 years ago
|
Comment 3•4 years ago
|
||
So, this is disappointing because I specifically tried to use the reduce-motion preferences to reduce the chances of this being a problem when implementing this solution, after your feedback in bug 1610081 that fixed borders helped with this. This is why the borders stay and the controls do not fade out.
For reasons of discoverability, we don't want to switch back to the control items being all the way on the side.
What other changes could we make that would improve the situation for you?
The version I'm getting now (a) starts with a box around it, (b) initially scrolls with the page, (c) then has the box disappear, and (d) no longer scrolls with the page.
So I think this would be easier with a clear vertical or horizontal separator, which doesn't fade when it's needed. And yes, I would much prefer more separation. Although here it's not likely to create accessibility problems like in about:preferences. I guess there's an inherent conflict between discoverability and motion-sensitive accessibility.
Comment 6•4 years ago
|
||
(In reply to MarjaE from comment #5)
The version I'm getting now (a) starts with a box around it, (b) initially scrolls with the page, (c) then has the box disappear, and (d) no longer scrolls with the page.
Do you not have macOS set up to reduce motion (see e.g. https://mcmw.abilitynet.org.uk/macos-mojave-reduce-motion )? That seems like it would generally be valuable for you. This will turn off (c). It should also turn off (b); that's a bug that's already on file. If you don't want to configure this in macOS, you can create the pref ui.prefersReducedMotion
set to the number 1
in about:config.
So I think this would be easier with a clear vertical or horizontal separator, which doesn't fade when it's needed.
If the border didn't fade (see above) and the item didn't move at all, would that be sufficient for you?
And yes, I would much prefer more separation. Although here it's not likely to create accessibility problems like in about:preferences. I guess there's an inherent conflict between discoverability and motion-sensitive accessibility.
In this case, maybe. As I said, I don't think we want to move the item away from the text; I guess if the above will not be sufficient using userContent.css
to hide or reposition the controls may be your best option...
At the system level, yes, it's set to Reduce Motion (not that the system follows its own settings), but somehow Firefox had that set to 0. Thanks.
Comment 8•4 years ago
|
||
Unfortunately, I don't think we're realistically going to change this UI in the short term. It's also not clear what would be a good alternative that doesn't have the discoverability drawbacks of the previous design.
Duplicate: bug 1649666.
Description
•