| Summary: | Move view-related functions from Frame to FrameView | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Darin Adler <darin> | ||||
| Component: | New Bugs | Assignee: | Darin Adler <darin> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | abarth, dglazkov, eric, jparent, simon.fraser, webkit-ews, webkit.review.bot | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Other | ||||||
| OS: | OS X 10.5 | ||||||
| Attachments: |
|
||||||
|
Description
Darin Adler
2010-05-19 10:22:20 PDT
Created attachment 56500 [details]
Patch
Attachment 56500 [details] did not build on qt: Build output: http://webkit-commit-queue.appspot.com/results/2265334 Attachment 56500 [details] did not build on chromium: Build output: http://webkit-commit-queue.appspot.com/results/2284350 Comment on attachment 56500 [details]
Patch
WebCore/css/CSSStyleSelector.cpp:4043
+ multiplier *= view->textZoomFactor();
much cleaner, thanks.
WebCore/dom/MouseRelatedEvent.cpp:137
+ float zoomFactor = pageZoomFactor(this);
MUCH cleaner. Thanks again!
WebCore/html/HTMLBodyElement.cpp:268
+ document->updateLayoutIgnorePendingStylesheets();
This is a behavior change. We didn't use to bother to layout when the view didn't exist. Is this intentional?
WebCore/page/FrameView.h:297
+ int m_borderX;
This is destined to be an IntSize in a later patch. :)
WebKit/efl/ewk/ewk_frame.cpp:974
+ return -1;
-1?
LGTM.
(In reply to comment #4) > WebCore/html/HTMLBodyElement.cpp:268 > + document->updateLayoutIgnorePendingStylesheets(); > This is a behavior change. We didn't use to bother to layout when the view didn't exist. Is this intentional? It was intentional. I think it's safer to call the layout update function before looking at anything, including the view's existence. > WebCore/page/FrameView.h:297 > + int m_borderX; > This is destined to be an IntSize in a later patch. :) I thought the same thing. > WebKit/efl/ewk/ewk_frame.cpp:974 > + return -1; > -1? Just following the design of this EFL function. They made it return -1 when there is no frame. I don't understand it -- that's the downside of each port having its own API. Different quirks. Committed r60104: <http://trac.webkit.org/changeset/60104> http://trac.webkit.org/changeset/60104 might have broken Qt Linux ARMv5 Release The following changes are on the blame list: http://trac.webkit.org/changeset/60104 http://trac.webkit.org/changeset/60101 http://trac.webkit.org/changeset/60102 http://trac.webkit.org/changeset/60103 I think this change broke Chromium's compile on all platforms too. (In reply to comment #8) > I think this change broke Chromium's compile on all platforms too. Has it been fixed yet? Everything looks OK on <http://build.webkit.org/waterfall> at this point, so maybe I fixed it or someone else did. The fix should be simple if it hasn't been done yet. Yup, tc fixed it last night in r60111. Thanks for following up! |