[Webkit-unassigned] [Bug 158902] js/dom/global-constructors-attributes.html is flaky: ResourceTiming runtime feature leaks between tests
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Jul 8 14:54:00 PDT 2016
https://bugs.webkit.org/show_bug.cgi?id=158902
Benjamin Poulain <benjamin at webkit.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |benjamin at webkit.org
--- Comment #40 from Benjamin Poulain <benjamin at webkit.org> ---
(In reply to comment #34)
> (In reply to comment #33)
> > Comment on attachment 282941 [details]
> > Patch
> >
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=282941&action=review
> >
> > Check this before landing:
> >
> > > Source/WebCore/bindings/generic/RuntimeEnabledFeatures.cpp:67
> > > - , m_isIndexedDBEnabled(false)
> > > + m_isIndexedDBEnabled = true;
> >
> > You are changing this default. Is is intended?
>
> It is intended, but I'm not 100% sure this is the right thing to do. See
> https://bugs.webkit.org/show_bug.cgi?id=158902#c31
>
> The default gets overridden to true in the mac and win WebViews as well as
> the WK2 port, and there are various tests that rely on it. But, other ports
> don't necessarily turn it on, so changing the default would change their
> behavior. So, I'm not sure what's the best course of action here
I prefer your previous approach. My previous r+ still holds.
For testing, we should have a common environment for all ports. If Mac and Win already enabled it by default, it sounds like the right thing to do is to enable it everywhere.
IndexedDB is an important feature anyway. It is beneficial for GTK and EFL to support it ASAP.
I would prefer if you land the previous patch with common features and a reset(). If that breaks the universe, we roll back and discuss what to do about GTK/EFL.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160708/a10f4739/attachment.html>
More information about the webkit-unassigned
mailing list