[chromium] Expose mock scrollbars to window.internals
Created attachment 114797 [details] Patch
Please wait for approval from fishd@chromium.org before submitting because this patch contains changes to the Chromium public API.
I realize that some ports set mock scrollbars on all the time, but I felt like exposing a per-test setting seemed more flexible. I'm hoping this patch will alleviate some of our scrollbar pixel difference woes.
Comment on attachment 114797 [details] Patch Attachment 114797 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/10448591
Created attachment 114810 [details] Now with more exports
Comment on attachment 114810 [details] Now with more exports Attachment 114810 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/10350700
Created attachment 114841 [details] Patch
Created attachment 114860 [details] Fourth try's a charm
(In reply to comment #8) > Created an attachment (id=114860) [details] > Fourth try's a charm This link error really makes no sense. Why is WebKit.dll referencing Internals.h? Shouldn't that be contained within WebCoreTestSupport? 11> Creating library C:\cygwin\home\buildbot\Webkit\WebKitBuild\Debug\lib\WebKit.lib and object C:\cygwin\home\buildbot\Webkit\WebKitBuild\Debug\lib\WebKit.exp 11>WebKit.exp : error LNK2001: unresolved external symbol "public: void __thiscall WebCore::Internals::setMockScrollbarsEnabled(class WebCore::Document *,bool,int &)" (?setMockScrollbarsEnabled@Internals@WebCore@@QAEXPAVDocument@2@_NAAH@Z)
Comment on attachment 114860 [details] Fourth try's a charm View in context: https://bugs.webkit.org/attachment.cgi?id=114860&action=review > Source/WebKit/chromium/public/WebSettings.h:107 > + virtual void setMockScrollbarsEnabled(bool) = 0; Chromium WebKit API changes LGTM
(In reply to comment #9) > (In reply to comment #8) > > Created an attachment (id=114860) [details] [details] > > Fourth try's a charm > > This link error really makes no sense. Why is WebKit.dll referencing Internals.h? Shouldn't that be contained within WebCoreTestSupport? WebCoreTestSupport is a static library that is linked into DRT and WTR and calls various WebCore functions. WebCore (on Windows) is a static library that is linked into WebKit.dll. For DRT/WTR to be able to call WebCore functions (via WebCoreTestSupport), those functions need to be exported from WebKit.dll. You can fix your linker error by adding the appropriate mangled symbols to WebKit2.def. You can see there are already multiple Internals-related functions listed there toward the bottom.
Created attachment 115179 [details] Oops. Don't export the wrong symbol from WebKit2.def, causing a linker error in WebKit.dll
(In reply to comment #11) > (In reply to comment #9) > > (In reply to comment #8) > > > Created an attachment (id=114860) [details] [details] [details] > > > Fourth try's a charm > > > > This link error really makes no sense. Why is WebKit.dll referencing Internals.h? Shouldn't that be contained within WebCoreTestSupport? > > WebCoreTestSupport is a static library that is linked into DRT and WTR and calls various WebCore functions. WebCore (on Windows) is a static library that is linked into WebKit.dll. > > For DRT/WTR to be able to call WebCore functions (via WebCoreTestSupport), those functions need to be exported from WebKit.dll. > > You can fix your linker error by adding the appropriate mangled symbols to WebKit2.def. You can see there are already multiple Internals-related functions listed there toward the bottom. Thanks for all the info and explanation. :) I think I see what happened. I copied and pasted the wrong symbol (the caller, not the callee) into WebKit2.def, so WebKit.dll expected that function to exist when it was building. Oops.
Created attachment 115182 [details] Rebaselined
Comment on attachment 115182 [details] Rebaselined R=me
Committed r100545: <http://trac.webkit.org/changeset/100545>