[Webkit-unassigned] [Bug 87993] window.internals is not good for changing persistent settings

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 11 16:37:25 PST 2013


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


Tony Chang <tony at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tony at chromium.org




--- Comment #4 from Tony Chang <tony at chromium.org>  2013-01-11 16:39:15 PST ---
Hi Alexey and Morria,

I was wondering what work remains for this bug.  Replying out of order:

> 2. If a test navigates to a different URL (with waitUntilDone/notifyDone), settings are restored from last document's InternalSettings instead of first one's, so changes made in first one just leak to future tests.

I think this was fixed by Morrita when he made the lifetime of InternalSettings match that of Page in bug 88499.

> 3. Code design is not very clear. Settings are per-page, yet many Internals methods take Document, Frame or a global context.

I moved everything off of internals.settings that doesn't have to do with the Settings class or RuntimeEnabledFeatures.  If you want, I can move all the RuntimeEnabledFeatures to internals.

> 1. Changing a setting in one window.internals.settings object affects all frames in a page, but does not work across secondary windows. This is inconsistent.

I guess this could be confusing, although given that there are only 186 files that call setCanOpenWindows, maybe that's OK?  It seems consistent that changes to internals.settings has the same scope as the Settings class, which is the Page, but maybe that's not obvious to most developers?

I'm not sure how we would solve this short of implementing something like Preferences that will keep all the Settings instances synchronized.  I'm not sure that's worth the code complexity.


Let me know how you would like to see internals and internals.settings improved.

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


More information about the webkit-unassigned mailing list