Bug 24070 - Changing "scrolling" attribute on iframe element already in DOM doesn't take effect
Summary: Changing "scrolling" attribute on iframe element already in DOM doesn't take ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Scrolling (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Matt Woodrow
URL:
Keywords: GoodFirstBug, InRadar
: 24972 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-20 19:47 PST by Tom Robinson
Modified: 2024-10-09 21:02 PDT (History)
10 users (show)

See Also:


Attachments
Reduction (185 bytes, text/html)
2009-02-20 19:48 PST, Tom Robinson
no flags Details
First attempt to fix the bug (5.67 KB, patch)
2009-02-26 18:36 PST, Bo Yang
zwarich: review-
Details | Formatted Diff | Diff
Reduction (297 bytes, text/html)
2022-08-19 21:14 PDT, Simon Fraser (smfr)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Robinson 2009-02-20 19:47:47 PST
Changing "scrolling" attribute on iframe element already in DOM doesn't take effect.

Works as expected in Firefox.
Comment 1 Tom Robinson 2009-02-20 19:48:21 PST
Created attachment 27847 [details]
Reduction
Comment 2 Bo Yang 2009-02-20 20:51:40 PST
conform on Windows Safari.
Comment 3 Bo Yang 2009-02-26 18:36:05 PST
Created attachment 28060 [details]
First attempt to fix the bug

Add a new method in FrameView to change the scrollbar's state and a test case for this bug.
Comment 4 Cameron Zwarich (cpst) 2009-03-31 18:22:35 PDT
*** Bug 24972 has been marked as a duplicate of this bug. ***
Comment 5 Cameron Zwarich (cpst) 2009-03-31 18:42:48 PDT
Comment on attachment 28060 [details]
First attempt to fix the bug

+        if (attached()) {

Is there any need to check attached() here? Shouldn't checking contentFrame() be enough? 

+            if (contentFrame() && contentFrame()->view()) {
+                FrameView* view = contentFrame()->view();
+                view->changeScrollbarsState(m_scrolling != ScrollbarAlwaysOff);
+            }
+        }

There is already a method on FrameView for setting the scrollbar state:

void setCanHaveScrollbars(bool canScroll);

You should use that instead of making your own. I'm r-'ing this patch, but I am glad that you are fixing this bug.
Comment 6 Ahmad Saleem 2022-08-10 17:26:46 PDT
I am able to reproduce this in Safari 15.6 on macOS using modified test case by changing HTTP to HTTPS in test case:

Link - https://jsfiddle.net/fcjd6qr8/

Following are results across browsers:

*** Firefox Nightly 105 ***

Once iframe load, clicking "show scrollbars" load "scrollbar" in iframe

*** Chrome Canary 106 ***

Nothing loads and "show scrollbars" do nothing.

*** Safari 15.6 on macOS 12.5 ***

Nothing loads and "show scrollbars" do nothing.

________

I am not sure on web-spec but just wanted to share updated testing results. Thanks!
Comment 7 Radar WebKit Bug Importer 2022-08-19 20:43:34 PDT
<rdar://problem/98911472>
Comment 8 Simon Fraser (smfr) 2022-08-19 21:14:58 PDT
Created attachment 461752 [details]
Reduction
Comment 9 Simon Fraser (smfr) 2022-08-19 21:22:25 PDT
HTMLFrameElementBase::parseAttribute() needs to respond to "scrolling" attribute changes.
Comment 10 Matt Woodrow 2024-10-08 20:17:23 PDT

*** This bug has been marked as a duplicate of bug 281103 ***
Comment 11 Matt Woodrow 2024-10-09 15:31:15 PDT
I'll fix this as a separate task.
Comment 13 EWS 2024-10-09 21:02:07 PDT
Committed 284947@main (d98621968e3c): <https://commits.webkit.org/284947@main>

Reviewed commits have been landed. Closing PR #34933 and removing active labels.