[Webkit-unassigned] [Bug 30291] When effectAllowed = "uninitialized", incorrect dropEffect returned

[bugzilla-daemon at webkit.org]

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





--- Comment #6 from Daniel Bates <dbates at webkit.org>  2009-11-10 17:01:09 PST ---
Filed a new bug #31326 with regards to cleaning up the output, which was just
r+'ed. I was able to get the prettier output by using shouldBeEqualToString as
opposed to shouldBe. 

>From looking at js-test-pre.js, shouldBe causes an exception to be thrown using
the line you provided because of line 102
<http://trac.webkit.org/browser/trunk/LayoutTests/fast/js/resources/js-test-pre.js#L102>,
in which eval(_b) is called. And if _b is a string, say "none", then
eval("none") will be interpreted as script code, instead of returning a string.

I will rebase the test with the passing of bug #31326 before I land this patch.

Thanks for your suggestion. This definitely makes the test much more beautiful.

(In reply to comment #5)
> (From update of attachment 42885 [details])
> r=me
> 
> But this test could be improved with one tiny change.
> 
> This line:
> 
>     shouldEvaluateTo('event.dataTransfer.dropEffect',
> 'dropEffectElem.options[dropEffectElem.selectedIndex].value');
> 
> Should be changed to:
> 
>     shouldBe('event.dataTransfer.dropEffect',
> dropEffectElem.options[dropEffectElem.selectedIndex].value);
> 
> This would then make the test output easy to read because you could see the
> actual result strings instead of the expression over and over again.
> 
> I'm really surprised by the shouldEvaluateTo function. I don't know who added
> it and when, and I think I should look into this a bit more. When the second
> argument is a string, it's the same as shouldBe, so I'm kind of mystified why
> we would need it in that case.

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