WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
31612
two layout tests assume java is disabled
https://bugs.webkit.org/show_bug.cgi?id=31612
Summary
two layout tests assume java is disabled
Dirk Pranke
Reported
2009-11-17 19:17:46 PST
Two layout tests ( fast/replaced/applet-disabled-positioned.html and fast/replaced/applet-rendering-java-disabled.html ) assume that java is disabled by default. This is true for Safari but isn't necessarily true in general (i.e., it isn't true for Chromium). The layoutTestController has hooks to control enabling / disabling Java, so we should use those.
Attachments
patch to the two test files.
(2.06 KB, patch)
2009-11-17 19:19 PST
,
Dirk Pranke
mrowe
: review-
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Dirk Pranke
Comment 1
2009-11-17 19:19:57 PST
Created
attachment 43396
[details]
patch to the two test files.
Mark Rowe (bdash)
Comment 2
2009-11-17 19:34:44 PST
Comment on
attachment 43396
[details]
patch to the two test files. DumpRenderTree is expected to disable Java. See: WebKitTools/DumpRenderTree/mac/DumpRenderTree.mm:407: [preferences setJavaEnabled:NO]; WebKitTools/DumpRenderTree/win/DumpRenderTree.cpp:723: preferences->setJavaEnabled(FALSE);
Dirk Pranke
Comment 3
2009-11-17 20:58:32 PST
That doesn't seem like a good thing. It means you can't actually test anything with applets in it, right? In particular, fast/dom/java-applet-calls.html has expected output that expects java to be disabled. Wouldn't it be better to actually have tests that make sure this works? I also saw a comment that these tests were intentionally done this way because DRT hangs when trying to load the JVM (dom/level2/html/AppletsCollection.html). It seems like it would be better to track that as a bug with failing tests rather than assume that this will never work.
Mark Rowe (bdash)
Comment 4
2009-11-17 21:41:22 PST
(In reply to
comment #3
)
> That doesn't seem like a good thing. It means you can't actually test anything > with applets in it, right?
I’m not sure why you think that. Whatever subset of tests that require Java could easily opt in to enabling it.
> In particular, fast/dom/java-applet-calls.html has expected output that expects > java to be disabled. Wouldn't it be better to actually have tests that make > sure this works? > > I also saw a comment that these tests were intentionally done this way because > DRT hangs when trying to load the JVM (dom/level2/html/AppletsCollection.html). > It seems like it would be better to track that as a bug with failing tests > rather than assume that this will never work.
I’m not sure how this relates to the statement I made.
Dirk Pranke
Comment 5
2009-11-17 22:17:23 PST
Ah, perhaps I misunderstood you. I thought you were saying that java should always be disabled in DRT. You're merely saying that we should assume disabled but can write tests to enable it if we like?
Mark Rowe (bdash)
Comment 6
2009-11-17 22:28:47 PST
(In reply to
comment #5
)
> Ah, perhaps I misunderstood you. I thought you were saying that java should > always be disabled in DRT. You're merely saying that we should assume disabled > but can write tests to enable it if we like?
I’m saying that the Chromium DRT should use the same settings that other ports use. Tests that need to test other functionality should enable it explicitly.
Dirk Pranke
Comment 7
2009-11-18 00:00:02 PST
Got it. Thanks for the clarification.
Dirk Pranke
Comment 8
2009-11-18 00:00:34 PST
I'll close this as WONTFIX, then.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug