Bug 208570 - frame/iframe scrolling attribute does to recognize value "noscroll" or "off"
Summary: frame/iframe scrolling attribute does to recognize value "noscroll" or "off"
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Frédéric Wang (:fredw)
URL:
Keywords: InRadar, WebExposed
Depends on: 209178
Blocks:
  Show dependency treegraph
 
Reported: 2020-03-04 03:08 PST by Frédéric Wang (:fredw)
Modified: 2020-03-18 11:13 PDT (History)
11 users (show)

See Also:


Attachments
WIP Patch (8.22 KB, patch)
2020-03-05 02:19 PST, Frédéric Wang (:fredw)
no flags Details | Formatted Diff | Diff
Patch (3.45 KB, patch)
2020-03-18 00:27 PDT, Frédéric Wang (:fredw)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frédéric Wang (:fredw) 2020-03-04 03:08:00 PST
From https://html.spec.whatwg.org/multipage/rendering.html#the-page:

> If a Document's browsing context is a child browsing context, the container of that browsing context is a frame or iframe element, that element has a scrolling attribute, and that attribute's value is an ASCII case-insensitive match for the string "off", "noscroll", or "no", then the user agent is expected to prevent any scrollbars from being shown for the viewport of the Document's browsing context, regardless of the 'overflow' property that applies to that viewport.

Source/WebCore/html/HTMLFrameElementBase.cpp only handles "no":

ScrollbarMode HTMLFrameElementBase::scrollingMode() const
{
    return equalLettersIgnoringASCIICase(attributeWithoutSynchronization(scrollingAttr), "no")
        ? ScrollbarAlwaysOff : ScrollbarAuto;
}

Gecko recognizes the three values and Chromium added support for them after fixing https://bugs.chromium.org/p/chromium/issues/detail?id=1057454

WPT test was added in https://chromium-review.googlesource.com/c/chromium/src/+/2085396
Comment 1 Frédéric Wang (:fredw) 2020-03-04 23:39:23 PST
This should be trivial fix. I can take care of this.
Comment 2 Frédéric Wang (:fredw) 2020-03-05 02:19:04 PST
Created attachment 392550 [details]
WIP Patch

WPT tests haven't arrived yet into the WPT repos, so we need to wait before taking this...
Comment 3 Mason Freed 2020-03-05 09:42:18 PST
WPT tests are hung up here: https://github.com/web-platform-tests/wpt/pull/22072
Comment 4 Simon Fraser (smfr) 2020-03-17 13:26:20 PDT
Are "off", "noscroll", or "no" synonymous?
Comment 5 Frédéric Wang (:fredw) 2020-03-17 14:18:03 PDT
(In reply to Simon Fraser (smfr) from comment #4)
> Are "off", "noscroll", or "no" synonymous?

In HTML5, yes (see comment 0).

Maybe this was different in HTML4.
Comment 6 Frédéric Wang (:fredw) 2020-03-18 00:27:37 PDT
Created attachment 393825 [details]
Patch
Comment 7 Rob Buis (away until 22nd August) 2020-03-18 09:48:48 PDT
Comment on attachment 393825 [details]
Patch

Approved also since Maciej indicated it as a reasonable change.
Comment 8 WebKit Commit Bot 2020-03-18 11:12:43 PDT
Comment on attachment 393825 [details]
Patch

Clearing flags on attachment: 393825

Committed r258651: <https://trac.webkit.org/changeset/258651>
Comment 9 WebKit Commit Bot 2020-03-18 11:12:45 PDT
All reviewed patches have been landed.  Closing bug.
Comment 10 Radar WebKit Bug Importer 2020-03-18 11:13:14 PDT
<rdar://problem/60592188>