1322952 - vertical scrollbar blocked by site

Status: RESOLVED INVALID

(Core :: Panning and Zooming, defect)

Description

[JDev]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161129173726

Steps to reproduce:

I went to twitter and a full page overlay appeared, I don't know for what as the content was adblocked blocked automatically.  I used AdBlock Element Hiding Helper to prevent the twitter.com##.modal-overlay from displaying again.  Upon doing so I realized that there was no vertical scrollbar present despite content loaded below the line.  I was able to use the keyboard to navigate it but it would not reappear until after I navigated away.

Comment 1

[Andre Klapper]

Why should this be a bug in Firefox and not in AdBlock?

Comment 2

[JDev]

Because Firefox allowed the modal/javascript(?) to dictate whether or not the scrollbar appeared, despite the content behind the overlay extending below the visible window.  The presence of AdBlock is immaterial, it merely changed the overlay's visibility, not the height of the content behind it.

Comment 3

[ovidiu boca[:Ovidiu]]

I tested on Windows 8.1 with FF 50 release with new profile and I can't reproduce it. 
If you try in safe mode do you see any changes? If you see changes I suspect the AdBlock fault here, if not is a Firefox issue, I think.

Comment 4

[JDev]

Attachment: Bug example

I was able to replicate it on another site by simply using Firebug to change the visibility of the overlay DIV to hidden.

I attached an image; left is with the overlay, middle is visibility hidden, right is after reloading without the overlay loading.  The height in all three is 4917px with a window of less than 900px.

Comment 5

[Botond Ballo [:botond]]

What I often see sites do is initially have overflow:hidden on the scrollable element, which inhibits the presence of a scrollbar, and then remove that property from script when the overlay is closed.

If AdBlock is only hiding the overlay, the script in question never runs, and the overflow:hidden property on the scrollable element persists.

If this is what's happening in this case, it's not clear what, if anything, Firefox could do about it.

Comment 6

[JDev]

A couple possibilities I can think of:

1) While the overflow:hidden element is visible scrolling by any means is not possible, when it is hidden keyboard scrolling is restored.  As well as restoring keyboard scrolling it could restore the sccrollbar at the same time.  

2) Only allow overflow:hidden on visible elements (not sure if this would be standards compliant or not).  The first solution would be preferable regardless.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

(In reply to JDev from comment #6)
> A couple possibilities I can think of:
> 
> 1) While the overflow:hidden element is visible scrolling by any means is
> not possible, when it is hidden keyboard scrolling is restored.  As well as
> restoring keyboard scrolling it could restore the sccrollbar at the same
> time.  

I think you're confusing the overflow:hidden element with the overlay. overflow:hidden is set on the scrolling document, explicitly to prevent it from scrolling. The overlay's visibility is independent. When sites use overlays like this, they want to prevent the user from scrolling the document in the background, which is why they set overflow:hidden on the document in the background. As Botond said in comment 5, the overflow:hidden style is removed when the user dismisses the overlay, usually as part of a script. If you're skipping the step to dismiss the overlay (because of adblocking or whatever), then the document will remain overflow:hidden, and hence remains intentionally unscrollable.

This definitely does not sound like a Firefox bug, assuming what's happening here is what Botond described in comment 5. Closing as INVALID for now, but feel free to argue your case further if you feel it is actually a bug in Firefox. Showing that Chrome behaves differently in the same scenario would help your case a great deal.

Comment 8

[JDev]

And this is why Firefox is losing market share hand over fist.  A missing interface element like this used to be a blocking issue but now "If Chrome does it different than we do".  Well I guess you want us to use Chrome more than Firefox so who am I to fight the tide.

Comment 9

[Botond Ballo [:botond]]

This is not a "missing interface element". This is the browser behaving as specified.

The CSS specification says that for overflow:hidden elements, "the content is clipped and that no scrolling user interface should be provided to view the content outside the clipping region" [1].

It's not the browser's job to decide "oh, in this case, the web developer is just being mean by not letting you scroll their page until you click through their overlay, so we'll actually ignore the overflow:hidden".

Firefox does provide a mechanism for users to modify their browsing experience in ways that may include rendering web content in nonstanadard ways: by installing addons. Nothing stops you from writing an addon that detects situations like this and removes the overflow:hidden style (or requesting that an existing addon, such as the AdBlock Element Hiding Helper, be enhanced to do so).

[1] https://www.w3.org/TR/CSS2/visufx.html#overflow

Comment 10

[JDev]

"A descendant box is positioned absolutely, partly outside the box. Such boxes are not always clipped by the overflow property on their ancestors; specifically, they are not clipped by the overflow of any ancestor between themselves and their containing block "

This indicates the intent of the standard isn't always that the content outside the box be clipped which means a scrollbar should likely be present on the UI for such cases.  

The specific language of the overflow text:

"hidden: This value indicates that the content is clipped and that no scrolling user interface should be provided to view the content outside the clipping region."

No UI to view the content outside the clipping region, well, what's a clipping region?  In the "clip" standard we're given a definition:  "A clipping region defines what portion of an element's border box is visible."  By my reading of this, if no portion of the element's border box is visible, there should be no clipping region for that element and no need to remove the scrollbar.

Comment 11

[Botond Ballo [:botond]]

(In reply to JDev from comment #10)
> "A descendant box is positioned absolutely, partly outside the box. Such
> boxes are not always clipped by the overflow property on their ancestors;
> specifically, they are not clipped by the overflow of any ancestor between
> themselves and their containing block "
> 
> This indicates the intent of the standard isn't always that the content
> outside the box be clipped which means a scrollbar should likely be present
> on the UI for such cases.

Not clipping does not imply showing a scrollbar. Rather the opposite: the purpose of a scrollbar is to bring into view content that has been clipped away.

> The specific language of the overflow text:
> 
> "hidden: This value indicates that the content is clipped and that no
> scrolling user interface should be provided to view the content outside the
> clipping region."
> 
> No UI to view the content outside the clipping region, well, what's a
> clipping region?  In the "clip" standard we're given a definition:  "A
> clipping region defines what portion of an element's border box is visible."
> By my reading of this, if no portion of the element's border box is visible,
> there should be no clipping region for that element and no need to remove
> the scrollbar.

The "border box" is the element's border and everything inside it. If "no portion of the element's border box is visible", then the element itself isn't visible. That's clearly not the situation you're interested in.


The larger point here is that "overflow:hidden means no scrollbars" is both clearly stated in the spec, and the established behaviour of all browsers. You're not going to find a loophole around it. As I mentioned before, if you'd like different behaviour, an addon is the way to go.

Comment 12

[JDev]

If no scrolling UI is provided for a position:absolute descendant that isn't clipped (ie: appears outside the clipping region), how could one view it if it's also outside the viewable area?  

https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#viewport

Recommends that the UA "should" present a scrollbar for the viewport which directly contradicts the "should" for overflow:hidden.  Both are recommended, but with some reasoned exceptions.

"It affects the clipping of all of the element's content except any descendant elements (and their respective content and descendants) whose containing block is the viewport or an ancestor of the element."

If you interpret this to include the scrollbar, which is not unreasonable given the context, the body is excluded from clipping/hiding the scrollbar while anything inside the body can be freely clipped/hidden.  

So the question is, which "should" is the better choice?  From a user perspective, I would argue that an author should not have the ability to break the GUI while simultaneously allowing scrolling by other methods.  Allowing them to control everything inside the initial containing element is reasonable, but removing a core UI element of the viewport? 

For me this is the only thing that makes any sort of sense from a user perspective.

Comment 13

[Botond Ballo [:botond]]

(In reply to JDev from comment #12)
> If no scrolling UI is provided for a position:absolute descendant that isn't
> clipped (ie: appears outside the clipping region), how could one view it if
> it's also outside the viewable area?  

position:absolute descendants are "not clipped by the overflow of any ancestor between themselves and their containing block". They still are clipped by their containing block, and the viewport is ultimately the containing block for everything, so everything is clipped by the viewport.

> https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#viewport
> 
> Recommends that the UA "should" present a scrollbar for the viewport which
> directly contradicts the "should" for overflow:hidden.  Both are
> recommended, but with some reasoned exceptions.
> 
> "It affects the clipping of all of the element's content except any
> descendant elements (and their respective content and descendants) whose
> containing block is the viewport or an ancestor of the element."
> 
> If you interpret this to include the scrollbar, which is not unreasonable
> given the context, the body is excluded from clipping/hiding the scrollbar
> while anything inside the body can be freely clipped/hidden.  
> 
> So the question is, which "should" is the better choice?  

A bit further down from your quote, the spec says:

"UAs must apply the 'overflow' property set on the root element to the viewport."

I think that makes it pretty clear that overflow behaviour applies to the viewport as well.

> From a user
> perspective, I would argue that an author should not have the ability to
> break the GUI while simultaneously allowing scrolling by other methods. 
> Allowing them to control everything inside the initial containing element is
> reasonable, but removing a core UI element of the viewport? 
> 
> For me this is the only thing that makes any sort of sense from a user
> perspective.

Note that overflow:hidden on the viewport has many interesting and useful use cases. For example, you can use it to implement a slideshow, where the page contains all the slides, but only one of them is visible at a time, and you advance to the next slide with a button or keypress.

Anyways, if you are proposing to ignore overflow:hidden on the viewport (by showing scrollbars) in general (rather than in some specific scenario related to ad blocking / overlay hiding), this bug is not the place to discuss that. Please take any further discussion to dev-platform [1], where people more familiar with the spec, its history, and its use cases, can weigh in.

[1] https://lists.mozilla.org/listinfo/dev-platform

Comment 14

[JDev]

> position:absolute descendants are "not clipped by the overflow of any ancestor between themselves and > their containing block". They still are clipped by their containing block, and the viewport is 
> ultimately the containing block for everything, so everything is clipped by the viewport.

It's initially clipped by the viewport by virtue of being outside the viable area but should be allowed to be scrolled to.

>A bit further down from your quote, the spec says:
>"UAs must apply the 'overflow' property set on the root element to the viewport."

You're leaving out the rest of that paragraph.  "The element from which the value is propagated must have a used value for 'overflow' of 'visible'.

I'll take my concerns there as what FF is doing currently is not right.