WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
143651
Legacy scroll behavior on HTMLBodyElement should only apply to the first body element of a document
https://bugs.webkit.org/show_bug.cgi?id=143651
Summary
Legacy scroll behavior on HTMLBodyElement should only apply to the first body...
Benjamin Poulain
Reported
2015-04-12 14:38:13 PDT
Legacy scroll behavior on HTMLBodyElement should only apply to the first body element of a document
Attachments
Patch
(58.37 KB, patch)
2015-04-12 14:43 PDT
,
Benjamin Poulain
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Benjamin Poulain
Comment 1
2015-04-12 14:43:57 PDT
Created
attachment 250619
[details]
Patch
Sam Weinig
Comment 2
2015-04-12 19:01:22 PDT
Comment on
attachment 250619
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=250619&action=review
> Source/WebCore/html/HTMLBodyElement.cpp:243 > + document().updateLayoutIgnorePendingStylesheets(); > + Frame* frame = document().frame(); > + if (!frame) > + return 0; > + FrameView* view = frame->view(); > + if (!view) > + return 0; > + return adjustForZoom(view->contentsScrollPosition().x(), *frame);
Will a layout ever change a contentsScrollPosition().x() which is equal to 0 to something that isn't equal to 0? If it never will, we should consider doing the optimization we have in DOMWindow::scrollX()/DOMWindow::scrollY() here.
Benjamin Poulain
Comment 3
2015-04-12 20:50:27 PDT
(In reply to
comment #2
)
> Comment on
attachment 250619
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=250619&action=review
> > > Source/WebCore/html/HTMLBodyElement.cpp:243 > > + document().updateLayoutIgnorePendingStylesheets(); > > + Frame* frame = document().frame(); > > + if (!frame) > > + return 0; > > + FrameView* view = frame->view(); > > + if (!view) > > + return 0; > > + return adjustForZoom(view->contentsScrollPosition().x(), *frame); > > Will a layout ever change a contentsScrollPosition().x() which is equal to 0 > to something that isn't equal to 0? If it never will, we should consider > doing the optimization we have in DOMWindow::scrollX()/DOMWindow::scrollY() > here.
You are probably right but given that this is legacy code, I don't think we should bother with speculative optimizations.
Benjamin Poulain
Comment 4
2015-04-12 21:43:49 PDT
Comment on
attachment 250619
[details]
Patch Clearing flags on attachment: 250619 Committed
r182677
: <
http://trac.webkit.org/changeset/182677
>
Benjamin Poulain
Comment 5
2015-04-12 21:43:54 PDT
All reviewed patches have been landed. Closing bug.
Darin Adler
Comment 6
2015-04-13 09:38:50 PDT
Comment on
attachment 250619
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=250619&action=review
> Source/WebCore/html/HTMLBodyElement.cpp:242 > + Frame* frame = document().frame(); > + if (!frame) > + return 0; > + FrameView* view = frame->view(); > + if (!view) > + return 0;
Document::view exists to make code sequences like this shorter: FrameView* view = document().view(); if (!view) return 0; Will be nice to have three fewer lines of code in every single one of these functions!
Benjamin Poulain
Comment 7
2015-04-14 14:33:29 PDT
(In reply to
comment #6
)
> Document::view exists to make code sequences like this shorter: > > FrameView* view = document().view(); > if (!view) > return 0; > > Will be nice to have three fewer lines of code in every single one of these > functions!
The code below needs both the Frame and the FrameView.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug