Platform specific code under DumpRenderTree/chromium

[Prasad Tammana]

I'm looking at implementing WebViewHost::runModal() under DumpRenderTree so I can enable tests using showModalDialog on chromium port.  Since runModal() implementation will be different for different platforms, should I create mac, win etc. under DumpRenderTree/chromium to put platform specific code.  This seems to be the first instance of platform specific code for the chromium port of DRT.

Thanks,

Prasad

[TAMURA, Kent]

We should introduce WebViewHost{Win,Gtk,Mac}.{cpp,mm}, or put such code to existing TestShell{Win,Gtk,Mac}.

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

--
TAMURA Kent
Software Engineer, Google

[Prasad Tammana]

Ah.  Cool.  I didn't realize that a) we already have platform specific code in DRT for chromium and b) that we don't follow the convention of putting such code under mac/win etc. directories but rather using a filename suffix.  I'll likely introduce WebViewHostMac, Win etc.  Thanks!

[Prasad Tammana]

Couple of other questions:

What's the difference between WebKit/chromium/public vs WebKit/chromium/third_party/WebKit/WebKit/chromium/public?  They seem to have the same files that's are slightly out of sync in some cases.

Chromium port implements WebView as an abstract class and has a derived class WebViewImpl that has the actual implementation.    Whereas other ports seem to just implement WebView as a concrete class.  Why does chromium port do it this other way?

Thanks,

Prasad

[Tony Chang]

On Wed, Sep 22, 2010 at 3:58 PM, Prasad Tammana <pra...@chromium.org> wrote:

Couple of other questions:

What's the difference between WebKit/chromium/public vs WebKit/chromium/third_party/WebKit/WebKit/chromium/public?  They seem to have the same files that's are slightly out of sync in some cases.

They should be the same.  There's a build step that copies the headers from WebKit/chromium/public to WebKit/chromium/third_party/WebKit/WebKit/chromium/public.  This is a hack to work around the fact that we use the full path in chromium code (e.g., code in src/webkit/glue tries to include headers from third_party/WebKit/WebKit/chromium/public).

tony

[Prasad Tammana]

Thanks.  I would've thought it'd be easier to fix chromium code to not use full paths...

Different question.  DumpRenderTree by default doesn't make the windows visible.  On mac port, this is done by setting the window co-ordinates to be offscreen and this this is done in createWebViewAndOffscreenWindow() function in DumpRenderTree.mm.  So on mac port I could make the window visible by just tweaking and I find that handy some times when testing.  Is there some way to do this on chromium port?  I looked around a bit but couldn't find anything.

Thanks,

Prasad

[Jeremy Orlow]

Is there a reason the headers are copied rather than generating forwarding headers?  Copying seems more fragile.

J

[Tony Chang]

You mean have a build script generate .h files in third_party/WebKit/WebKit/chromium/public that includes the files from the webkit checkout?  That seems a bit better: it would be more obvious where the real headers are coming from.  I'm not sure if it would be more or less fragile.  Anyway, I've filed crbug.com/56677 to discuss.

[Jeremy Orlow]

For the record, this just bit me...

[Tony Chang]

Can you provide more detail?  Did the files not copy or did you edit the files in third_party/WebKit/WebKit/chromium/public?

[Jeremy Orlow]

I opened some of the files via the "Open quickly" menu in xcode and apparently I opened the copy.  I spent about 5 minutes trying to figure out why the compiler was telling me the method didn't exist before I remembered this thread and found out I was editing a copy.

J