[Webkit-unassigned] [Bug 42612] DRT should allow test scripts to access WebCore internal states for setup/verification

Wed Jul 28 02:03:34 PDT 2010

https://bugs.webkit.org/show_bug.cgi?id=42612

--- Comment #21 from MORITA Hajime <morrita at google.com>  2010-07-28 02:03:33 PST ---
Hi everyone, thank you for your feedback!
Updated patch disables WebCore::LTC on production build.

> 
> LayoutTests/fast/dom/Window/window-layout-test-controller-webcore.html:1
>  +  <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
> Can we just change this to <!DOCTYPE html> ?  Feel free to fix them all in a followup patch.
It looks OK because this file is generated by make-script-test-wrappers like other script tests.

(In reply to comment #16)
> (From update of attachment 62639 [details])
> I looked at the webkit-dev thread, and I don't see consensus that this is a good idea.  It's scary to me.
Yes, a series of patches is for a starting point of discussion. 
I'd like to continue to discuss here because most of interest party is already in CC list.

In my understanding, what bad is current trend of DRT testing which disallow manual testing.
This patch might not solve the problem though I hope this helps, 
but it would approaches other problem, as discussed on webkit-dev thread.

(In reply to comment #18)
> It does seem important for this object not to be exposed in production builds. Maybe not in nightly builds, either.
Agreed.
I disabled it on production build. But I have no idea which configuration is used for nightly build. 
I think WebCore::LTC should be enabled on Release build because we use Release build of DRT.

(In reply to comment #19)
> > What exactly is scary?
> 
> We don't want this to be part of the web platform.  That means we want it turned off in non-testing builds.  Also, we want to be sure we're not doing to screw up and expose it by accident.  Having the layoutTestController in a separate project makes that much harder to screw up.

Creating a separate project doesn't help an original goal of the patch.
By making LTC different framework, we

- need to export more symbols from WebCore framework for accessing from LTC.
- need to provide the way to access WebCore internal object (like WebCore::Frame).
 Such are possibly worse than just to allow LTC staying inside the WebCore.

On the other hand, I agree that making LTC available in accident could be a tragedy.
I hope the design have such case in mind.
On availability for JS world, It's simply hard to access it 
because applications need to 

- explicitly instantiate it, an
- explicitly put it into the context.

WebCore::LTC isn't accessible existing DOM object graph. 
So it wouldn't be possible unless intentional.

I'll be happy to hear your opinions more.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.