Bug 39054 – [DRT/Chromium] Fix a repaint issue and textarea tests

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Kent Tamura]

[DRT/Chromium] Fix repaint, WebGL, textarea tests

[Kent Tamura]

Created attachment 55960 [details]
Proposed patch

[Dimitri Glazkov (Google)]

Comment on attachment 55960 [details]
Proposed patch

WebKit/chromium/WebKit.gyp:607
 +                                  '<(chromium_src_dir)/webkit/tools/test_shell/resources/textAreaResizeCorner.png',
We probably shouldn't reach into a Chromium checkout here, right?

[Kent Tamura]

(In reply to comment #2)
> (From update of attachment 55960 [details])
> WebKit/chromium/WebKit.gyp:607
>  +                                  '<(chromium_src_dir)/webkit/tools/test_shell/resources/textAreaResizeCorner.png',
> We probably shouldn't reach into a Chromium checkout here, right?

I see.  This path seems very specific and we had better avoid it.

So we shoud ...
  - Copy textAreaResizeCorner.png to SHARED_INTERMEDIATE_DIR in webkit_support.gyp
  - WebKit.gyp refer to SHARED_INTERMEDIATE_DIR

[Dimitri Glazkov (Google)]

Sounds good.

[Kent Tamura]

Created attachment 56059 [details]
Proposed patch (rev.2)

[Kent Tamura]

>   - Copy textAreaResizeCorner.png to SHARED_INTERMEDIATE_DIR in webkit_support.gyp

This was done by Chromium r47248.

[Dimitri Glazkov (Google)]

Comment on attachment 56059 [details]
Proposed patch (rev.2)

Thank you so much!

[Adam Barth]

Attachment 56059 [details] was posted by a committer and has review+, assigning to Kent Tamura for commit.

[Adam Barth]

Comment on attachment 56059 [details]
Proposed patch (rev.2)

I have a bad feeling about this patch, but let's give it a go.

[WebKit Commit Bot]

Comment on attachment 56059 [details]
Proposed patch (rev.2)

Clearing flags on attachment: 56059

Committed r59571: <http://trac.webkit.org/changeset/59571>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Eric Seidel (no email)]

I think this broke cr win but due to dependency issues we did not notice until one commit later.

[Eric Seidel (no email)]

Yes, I believe we hit https://bugs.webkit.org/show_bug.cgi?id=38926, which caused this to not fail immediately after checkin but rather after the next change which caused a larger rebuild.

[Eric Seidel (no email)]

Actually, I think this break might just be a symptom of https://bugs.webkit.org/show_bug.cgi?id=38926 directly.  It's possible with a full rebuild that CrDRT would build just fine... not sure?


12>   Creating library C:\WebKitBuildSlave\chromium-win-release\build\WebKit\chromium\Release\lib\DumpRenderTree.lib and object C:\WebKitBuildSlave\chromium-win-release\build\WebKit\chromium\Release\lib\DumpRenderTree.exp
12>webcore_bindings.lib(V8DerivedSources3.obj) : error LNK2019: unresolved external symbol "public: __thiscall WebCore::ArrayBuffer::~ArrayBuffer(void)" (??1ArrayBuffer@WebCore@@QAE@XZ) referenced in function "public: void * __thiscall WebCore::ArrayBuffer::`scalar deleting destructor'(unsigned int)" (??_GArrayBuffer@WebCore@@QAEPAXI@Z)
12>webcore_bindings.lib(V8DerivedSources6.obj) : error LNK2001: unresolved external symbol "public: __thiscall WebCore::ArrayBuffer::~ArrayBuffer(void)" (??1ArrayBuffer@WebCore@@QAE@XZ)
12>webcore_bindings.lib(V8DerivedSources3.obj) : error LNK2019: unresolved external symbol "public: unsigned int __thiscall WebCore::ArrayBuffer::byteLength(void)const " (?byteLength@ArrayBuffer@WebCore@@QBEIXZ) referenced in function "class v8::Handle<class v8::Value> __cdecl WebCore::ArrayBufferInternal::byteLengthAttrGetter(class v8::Local<class v8::String>,class v8::AccessorInfo const &)" (?byteLengthAttrGetter@ArrayBufferInternal@WebCore@@YA?AV?$Handle@VValue@v8@@@v8@@V?$Local@VString@v8@@@4@ABVAccessorInfo@4@@Z)
12>webcore_bindings.lib(V8DerivedSources3.obj) : error LNK2019: unresolved external symbol "public: static class v8::Handle<class v8::Value> __cdecl WebCore::V8ArrayBuffer::constructorCallback(class v8::Arguments const &)" (?constructorCallback@V8ArrayBuffer@WebCore@@SA?AV?$Handle@VValue@v8@@@v8@@ABVArguments@4@@Z) referenced in function "class v8::Persistent<class v8::FunctionTemplate> __cdecl WebCore::ConfigureV8ArrayBufferTemplate(class v8::Persistent<class v8::FunctionTemplate>)" (?ConfigureV8ArrayBufferTemplate@WebCore@@YA?AV?$Persistent@VFunctionTemplate@v8@@@v8@@V23@@Z)

[Eric Seidel (no email)]

I seem to be unable to get the cr win builder to do a clean build (using the abort during the svn update step trick).  So I"m going to roll this out in hopes of re-greening the tree.

[Eric Seidel (no email)]

Reverted r59571 for reason:

Broke Cr Win, but we didn't notice immediately due to https://bugs.webkit.org/show_bug.cgi?id=38926.  It's possible that this didn't actually break Cr Win, but rather that bug 38926 necessitates a clean compile after this and sucessive checkins only produced a partial recompile and thus failed to build.

Committed r59578: <http://trac.webkit.org/changeset/59578>

[Eric Seidel (no email)]

Basically, I wasn't able to sort this out myself on the bots.  Someone with a Cr Win checkout will need to take a look and either hack around bug 38926 or simply fix it when landing this again. :)

[Kent Tamura]

We added a workaround for the features change issue.
I'll re-land the patch of this bug.

[Kent Tamura]

I landed as r59650, and reverted it as r59651.
The workaround didn't work well.

[Kent Tamura]

I'll land the patch without the features.gypi change.

[Kent Tamura]

Landed as r59744.