Re: [webkit-dev] "Magic Iframe" removal proposed

[Aaron Boodman]

I actually do know of at least one WebKit-only application under
development at Google that may be using this feature (I recently
suggested it to them).

Oh well.

- a

On Tue, Mar 20, 2012 at 8:07 AM, Adam Barth  wrote:
> Yeah, normally I would have waited longer, but the patch fixed a crash in
> WebKit2 that was making the bots red.  There was a discussion in another bug
> (sorry, don't have the link handy) where folks graciously held off fixing
> the crash, and I didn't want them to wait any longer than necessary.
>
> Adam
>
> On Mar 20, 2012 1:31 AM, "Maciej Stachowiak"  wrote:
>>
>>
>> I'm ok with removing this feature for the reasons you described. I concur
>> with others who think we should update the spec. I am also skeptical of
>> state sharing features that work via newer, less tested API surface instead
>> of latching onto existing features. That seems like a more risky strategy
>> since it may be harder to remove such a feature without compat breakage, and
>> it's not clear how it makes the security problems even easier.
>>
>> As a side note, this probably should have had more discussion time before
>> being actually committed. If a change is worthy of webkit-dev discussion in
>> the first place, then 5 hours between initial webkit-dev post and committing
>> the patch is cutting it a bit short. Especially when it is outside normal
>> working hours in the time zones where most WebKit contributors live. I don't
>> want to harp on this too much, since I don't personally disagree with the
>> change, but if anyone does, then they may feel that they didn't really get a
>> fair chance to comment.
>>
>> Regards,
>> Maciej
>>
>>
>> On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote:
>>
>> Hi,
>>
>> There is a patch posted for removal of the 'magic iframe' feature. This is
>> the ability to move 'live' iframe from one page to another w/o unloading it.
>> If you have interest or ideas about this feature, please reply.
>>
>> HISTORY
>> This feature was added 2 years ago (bug here). It was intended as a shared
>> app context for complex apps that span several pages. In case when random
>> set of pages is closed, the surviving iframe could be passed between
>> remaining pages and serve as 'app state'.
>> This behavior is somewhat described in HTML5 spec: "Removing an iframe
>> from a Document does not cause its browsing context to be discarded. Indeed,
>> an iframe's browsing context can survive its original parent Document if its
>> iframe is moved to another Document."
>> All non-WebKit browsers don't have this and always unload the iframe when
>> it is disconnected form the document.
>>
>> PROBLEMS
>> We did have quite a few issues with this mechanism. The root of the
>> problem seems to be that traditionally, multiple 'permissions' and 'live
>> objects' are associated with a top-level page, or a top frame of some kind,
>> instead of being associated with each Frame. Even HTML specifications often
>> formulate the scope of things like permissions in terms of a page - for
>> example, geo permissions are computed based on the origin of the page. When
>> an iframe is transferred from one page to another, it may enter a different
>> set of permissions while already performing operations authorized
>> before. Association with the top-level page is also used to determine which
>> one should show modal UI for HTTP Auth, per-origin permissions, or
>> certificate issues for example.
>> As a result, we had quite a few bugs popping up (and fixed).
>>
>> WHY REMOVE
>> This is somewhat obscure feature of the platform. Only a few apps that we
>> knew used the feature. Most developers, both app and webkit kind, don't even
>> know about it. When new mechanisms/APIs are implemented, a lot of objects
>> get associated with Page (WebView) level and they are almost 'automatically'
>> broken in case of live iframe transfer because once old page closes, it
>> destroys the objects with lifetimes scoped by it. This makes it somewhat
>> dangerous and difficult to support. The benefits that it gives to the big
>> multi-page applications do not seem to warrant the actual complexity of
>> maintaining this feature.
>> Other browsers never implemented the feature, siting difficult design due
>> to various thorny security issues as well.
>>
>> This is potentially a compatibility issue for sites that use
>> document.adoptNode(iframe) to ensure live transfer of an iframe from one
>> page to another.
>> In the future, if there will be sufficient need, it is possible to design
>> a 'shared module' feature that would explicitly deal with various
>> security/lifetime boundaries.
>>
>> Please let us know what you think.
>>
>> Thanks,
>> Dmitry
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webki

Re: [webkit-dev] Moving WTF out of JavaScriptCore

[Eric Seidel]

We're ready to complete the move.

https://bugs.webkit.org/show_bug.cgi?id=80911 should land later this
evening, moving JavaScriptCore/wtf/Platform.h to Source/WTF/Platform.h

Tomorrow (Weds) I will move a .cpp file in the same way.

Thursday, I will move all the rest of the WTF files.  I will also
update svn-apply so that in-flight patches should transparently patch
the right files post-move.

Let me know if you have questions or concerns.

-eric

On Tue, Feb 28, 2012 at 3:53 PM, Eric Seidel  wrote:
> I'm going to push off the move, probably until next week.
>
> Thank you for the Qt patch!
>
> I'll post a patch for Mark and we can discuss further from there.
>
> -eric
>
> On Tue, Feb 28, 2012 at 7:38 AM, Osztrogonac Csaba  
> wrote:
>> Hi,
>>
>> I uploaded the necessary buildfix for Qt to the bugzilla:
>> https://bugs.webkit.org/show_bug.cgi?id=79783 .
>>
>> Please be careful with moving JavaScriptCore/wtf to WTF, because we
>> need zillion trivial fixes for case sensitive file systems. (~4000 files!!!)
>>
>> I made it locally to be able prepare the Qt buildfix and I had to replace
>> all
>> "wtf" to "WTF includes everywhere. (*.cpp, *.h, *.y, *.py, *.pl, *.pm, ...)
>> The patch is huge, ~2Mb and ~4000 files are affected.
>>
>> I suggest landing the following patches separately:
>> - Moving Sources/JavaScriptCore/wtf --> Sources/WTF
>> - s/wtf/WTF/g patch :)
>> - platform buildfixes
>>
>> Please let me know if you have the new date for landing these patches. I
>> would be happier with a more CET timezone friendly timing. - 08:00-00:00 in
>> CET.
>>
>> br,
>> Ossy
>>
>> Eric Seidel írta:
>>
>>> We've been talking about moving WTF out of JavaScriptCore for a long
>>> time.  We believe we're nearly there.
>>> https://bugs.webkit.org/show_bug.cgi?id=75673
>>>
>>> This will mean that WTF will be built as a separate static library on all
>>> ports.
>>>
>>> The plan is to do this move all in one piece, after work hours PST,
>>> when the tree is least active.
>>>
>>> It won't be the most beautiful transition (as we're likely to break at
>>> least one port in the process), but we'll try not to make too much of
>>> a mess.
>>>
>>> We believe all the ports are ready for the move, except AppleWin:
>>> https://bugs.webkit.org/show_bug.cgi?id=75897
>>>
>>> Once AppleWin is ready we'll schedule a date for the transition and
>>> announce it one this thread.
>>>
>>> Thanks!
>>>
>>> -eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Git/SVN is slow

[William Siegrist]

On Mar 16, 2012, at 9:54 AM, William Siegrist  wrote:

> On Mar 16, 2012, at 9:26 AM, Ryosuke Niwa  wrote:
> 
>> As I stated on this thread, I was getting reasonable download speed from svn 
>> and others at home (Comcast business in SF). You may want to compare my 
>> traceroute to others and see if there's a difference.
>> 
> 
> 
> I have been comparing them and do not see a pattern. I've gotten reports of 
> people both near and far having both fast and slow downloads, and the problem 
> has been reported against more than 1 service and more than 1 piece of 
> hardware.
> 


I'm seeing many fewer clients connected to git and svn. I'm hoping that means 
the bandwidth problem went away and the backlog has cleared? Is anyone still 
having problems with a slow connection?

-Bill
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] 2012 WebKit Contributors' meeting

[Sam Weinig]

Apple will once again be hosting a WebKit Contributors Meeting. It will be held 
at the Cypress Hotel in Cupertino, CA on April 19 and 20. This meeting is for 
contributors to the WebKit Open Source Project. As with the meeting last year, 
this event will have an "unconference"-like format, allowing plenty of time for 
impromptu sessions/discussions and hacking.

The meeting will be free of charge. All WebKit contributors are encouraged to 
attend. However, space is limited, so registrations will be accepted on a 
first-come, first-served basis.

Please register for the conference using the form at 
https://www.webkit.org/meeting/ by April 11. When you register, you will 
automatically be subscribed to webkit-meet...@lists.webkit.org, which will be 
used for general discussion and to communicate additional information about the 
meeting.

If you have any questions about the meeting, or about whether this meeting is 
appropriate for you to attend, you may email me at wei...@apple.com.

We hope to see you there!

Thanks,
Sam Weinig

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Ambiguity in the style guide

[Darin Adler]

Yes, the general principle is to match the case sensitive sorting done by old 
school Unix command-line sort tool with no option. Not because there is any 
specific benefit to that particular order, just that there is a benefit to an 
unambiguous order.

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Anyone using NEON code on ARM builds?

[Dean Jackson]

Hi Jonathan,

On 21/03/2012, at 12:56 AM, Jonathan Kliegman wrote:

> On Wed, Mar 14, 2012 at 2:14 PM, Dean Jackson  wrote:
> Hi,
> 
> There are three files with embedded NEON code to speed up filters:
> 
> ./Source/WebCore/platform/graphics/filters/arm/FECompositeArithmeticNEON.{h,cpp}
> ./Source/WebCore/platform/graphics/filters/arm/FEGaussianBlurNEON.{h,cpp}
> ./Source/WebCore/platform/graphics/filters/arm/FELightingNEON.{h,cpp}
> 
> Are any ARM ports using this? (would require SVG and FILTERS both enabled) If 
> so, could you contact me? Off list is fine.
> 
> I see the code came from Felician Marton via Zoltan reviewed by Dirk (eg. 
> https://bugs.webkit.org/show_bug.cgi?id=65522) and it's been very slightly 
> touched for some chromium build issues.
> 
> Chrome OS has ports that use NEON and has SVG and FILTERS both enabled so 
> this would still be used.

Excellent!

Zoltan and I have been chatting offline a bit. I was testing compilation on 
Darwin/iOS ARM and running into a few issues. The first was about alignment 
errors from the compiler. The second was some linking issues, for example:

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

Is there someone (you?) on the Chrome team I should CC on any bugs raises?

Dean


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] "Magic Iframe" removal proposed

[Adam Barth]

Yeah, normally I would have waited longer, but the patch fixed a crash in
WebKit2 that was making the bots red.  There was a discussion in another
bug (sorry, don't have the link handy) where folks graciously held off
fixing the crash, and I didn't want them to wait any longer than necessary.

Adam
 On Mar 20, 2012 1:31 AM, "Maciej Stachowiak"  wrote:

>
> I'm ok with removing this feature for the reasons you described. I concur
> with others who think we should update the spec. I am also skeptical of
> state sharing features that work via newer, less tested API surface instead
> of latching onto existing features. That seems like a more risky strategy
> since it may be harder to remove such a feature without compat breakage,
> and it's not clear how it makes the security problems even easier.
>
> As a side note, this probably should have had more discussion time before
> being actually committed. If a change is worthy of webkit-dev discussion in
> the first place, then 5 hours between initial webkit-dev post and
> committing the patch is cutting it a bit short. Especially when it is
> outside normal working hours in the time zones where most WebKit
> contributors live. I don't want to harp on this too much, since I don't
> personally disagree with the change, but if anyone does, then they may feel
> that they didn't really get a fair chance to comment.
>
> Regards,
> Maciej
>
>
> On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote:
>
> Hi,
>
> There is a patch posted for 
> removal of the 'magic iframe' feature. This is the ability to move
> 'live' iframe from one page to another w/o unloading it.
> If you have interest or ideas about this feature, please reply.
>
> HISTORY
> This feature was added 2 years ago (bug 
> here).
> It was intended as a shared app context for complex apps that span several
> pages. In case when random set of pages is closed, the surviving iframe
> could be passed between remaining pages and serve as 'app state'.
> This behavior is somewhat described in HTML5 
> spec:
> "Removing an iframe from a Document does not cause its browsing context to
> be discarded. Indeed, an iframe's browsing context can survive its original
> parent Document if its iframe is moved to another Document."
> All non-WebKit browsers don't have this and always unload the iframe when
> it is disconnected form the document.
>
> PROBLEMS
> We did have quite a few issues with this mechanism. The root of the
> problem seems to be that traditionally, multiple 'permissions' and 'live
> objects' are associated with a top-level page, or a top frame of some kind,
> instead of being associated with each Frame. Even HTML specifications often
> formulate the scope of things like permissions in terms of a page - for
> example, geo permissions are computed based on the origin of the page. When
> an iframe is transferred from one page to another, it may enter a different
> set of permissions while already performing operations authorized
> before. Association with the top-level page is also used to determine which
> one should show modal UI for HTTP Auth, per-origin permissions, or
> certificate issues for example.
> As a result, we had quite a few bugs popping up (and fixed).
>
> WHY REMOVE
> This is somewhat obscure feature of the platform. Only a few apps that we
> knew used the feature. Most developers, both app and webkit kind, don't
> even know about it. When new mechanisms/APIs are implemented, a lot of
> objects get associated with Page (WebView) level and they are almost
> 'automatically' broken in case of live iframe transfer because once old
> page closes, it destroys the objects with lifetimes scoped by it. This
> makes it somewhat dangerous and difficult to support. The benefits that it
> gives to the big multi-page applications do not seem to warrant the actual
> complexity of maintaining this feature.
> Other browsers never implemented the feature, siting difficult design due
> to various thorny security issues as well.
>
> This is potentially a compatibility issue for sites that use
> document.adoptNode(iframe) to ensure live transfer of an iframe from one
> page to another.
> In the future, if there will be sufficient need, it is possible to design
> a 'shared module' feature that would explicitly deal with various
> security/lifetime boundaries.
>
> Please let us know what you think.
>
> Thanks,
> Dmitry
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit

Re: [webkit-dev] [GTK] GtkLauncher segfault

[Sergio Villar Senin]

En 20/03/12 15:42, 박상호 escribiu:
> hi,
> 
> I meet this seg-fault always. somebody help me?

That's an already known bug in WebKit, the code hits an ASSERT whenever
you try to convert icon image data to port specific image data. See
https://bugs.webkit.org/show_bug.cgi?id=67582 for more details.

If you still want to use the debug version of GtkLauncher you can
workaround the assert just by commenting the whole iconLoadedCb()
function in Tools/GtkLauncher/main.c (by doing that you won't get
favicons in the url entry).

BR

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] [GTK] GtkLauncher segfault

[박상호]

hi,

I meet this seg-fault always. somebody help me?

[Build Mode]
--gtk --debug --web-audio --fullscreen-api --no-svg

[SVN Revision]
r111378

[O/S]
Linux 3.2.0-19-generic #30-Ubuntu SMP Fri Mar 16 16:27:15 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux

[Log]
$ ./WebKitBuild/Debug/Programs/GtkLauncher
ASSERTION FAILED: m_verifier.isSafeToUse()
../../Source/JavaScriptCore/wtf/RefCounted.h(53) : void
WTF::RefCountedBase::ref()
1   0x7f625b8ac351
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0xc27351)
[0x7f625b8ac351]
2   0x7f625b8e6a20
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0xc61a20)
[0x7f625b8e6a20]
3   0x7f625c0bd2ee
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0x14382ee)
[0x7f625c0bd2ee]
4   0x7f625c2223d7
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0x159d3d7)
[0x7f625c2223d7]
5   0x7f625c22abb3
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0x15a5bb3)
[0x7f625c22abb3]
6   0x7f625c22a848
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0x15a5848)
[0x7f625c22a848]
7   0x7f625c22a5e2
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0x15a55e2)
[0x7f625c22a5e2]
8   0x7f625c1eacb8
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0x1565cb8)
[0x7f625c1eacb8]
9   0x7f625c194174
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0x150f174)
[0x7f625c194174]
10  0x7f625c194952
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0x150f952)
[0x7f625c194952]
11  0x7f625c90051e
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0x1c7b51e)
[0x7f625c90051e]
12  0x7f625b8cd858
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0xc48858)
[0x7f625b8cd858]
13  0x7f625b8cda96
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(webkit_favicon_database_try_get_favicon_pixbuf+0x13f)
[0x7f625b8cda96]
14  0x7f625b8fdfad
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(webkit_web_view_try_get_favicon_pixbuf+0xc8)
[0x7f625b8fdfad]
15  0x4038ad ./WebKitBuild/Debug/Programs/GtkLauncher() [0x4038ad]
16  0x7f6259e93a24
/o/WebKit/WebKitBuild/Dependencies/Root/lib64/libgobject-2.0.so.0(g_closure_invoke+0x154)
[0x7f6259e93a24]
17  0x7f6259ea3775
/o/WebKit/WebKitBuild/Dependencies/Root/lib64/libgobject-2.0.so.0(+0x1e775)
[0x7f6259ea3775]
18  0x7f6259eab14b
/o/WebKit/WebKitBuild/Dependencies/Root/lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x60b)
[0x7f6259eab14b]
19  0x7f6259eab312
/o/WebKit/WebKitBuild/Dependencies/Root/lib64/libgobject-2.0.so.0(g_signal_emit+0x82)
[0x7f6259eab312]
20  0x7f625b8fe2d3
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(webkitWebViewIconLoaded+0x73)
[0x7f625b8fe2d3]
21  0x7f6259e93a24
/o/WebKit/WebKitBuild/Dependencies/Root/lib64/libgobject-2.0.so.0(g_closure_invoke+0x154)
[0x7f6259e93a24]
22  0x7f6259ea3775
/o/WebKit/WebKitBuild/Dependencies/Root/lib64/libgobject-2.0.so.0(+0x1e775)
[0x7f6259ea3775]
23  0x7f6259eab14b
/o/WebKit/WebKitBuild/Dependencies/Root/lib64/libgobject-2.0.so.0(g_signal_emit_valist+0x60b)
[0x7f6259eab14b]
24  0x7f6259eab824
/o/WebKit/WebKitBuild/Dependencies/Root/lib64/libgobject-2.0.so.0(g_signal_emit_by_name+0x504)
[0x7f6259eab824]
25  0x7f625b8ced90
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0xc49d90)
[0x7f625b8ced90]
26  0x7f625c0ae3a0
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0x14293a0)
[0x7f625c0ae3a0]
27  0x7f625c0ad0da
/o/WebKit/WebKitBuild/Debug/.libs/libwebkitgtk-3.0.so.0(+0x14280da)
[0x7f625c0ad0da]
28  0x7f6259021d35
/o/WebKit/WebKitBuild/Debug/.libs/libjavascriptcoregtk-3.0.so.0(_ZN3WTF31dispatchFunctionsFromMainThreadEv+0x10e)
[0x7f6259021d35]
29  0x7f6259021aef
/o/WebKit/WebKitBuild/Debug/.libs/libjavascriptcoregtk-3.0.so.0(+0x66aaef)
[0x7f6259021aef]
30  0x7f6259bb053b
/o/WebKit/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0(+0x4753b)
[0x7f6259bb053b]
31  0x7f6259baf8fa
/o/WebKit/WebKitBuild/Dependencies/Root/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x16a)
[0x7f6259baf8fa]
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Anyone using NEON code on ARM builds?

[Jonathan Kliegman]

On Wed, Mar 14, 2012 at 2:14 PM, Dean Jackson  wrote:

> Hi,
>
> There are three files with embedded NEON code to speed up filters:
>
>
> ./Source/WebCore/platform/graphics/filters/arm/FECompositeArithmeticNEON.{h,cpp}
> ./Source/WebCore/platform/graphics/filters/arm/FEGaussianBlurNEON.{h,cpp}
> ./Source/WebCore/platform/graphics/filters/arm/FELightingNEON.{h,cpp}
>
> Are any ARM ports using this? (would require SVG and FILTERS both enabled)
> If so, could you contact me? Off list is fine.
>
> I see the code came from Felician Marton via Zoltan reviewed by Dirk (eg.
> https://bugs.webkit.org/show_bug.cgi?id=65522) and it's been very
> slightly touched for some chromium build issues.
>

Chrome OS has ports that use NEON and has SVG and FILTERS both enabled so
this would still be used.





>

Thanks,
>
> Dean
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] "Magic Iframe" removal proposed

[Maciej Stachowiak]

I'm ok with removing this feature for the reasons you described. I concur with 
others who think we should update the spec. I am also skeptical of state 
sharing features that work via newer, less tested API surface instead of 
latching onto existing features. That seems like a more risky strategy since it 
may be harder to remove such a feature without compat breakage, and it's not 
clear how it makes the security problems even easier.

As a side note, this probably should have had more discussion time before being 
actually committed. If a change is worthy of webkit-dev discussion in the first 
place, then 5 hours between initial webkit-dev post and committing the patch is 
cutting it a bit short. Especially when it is outside normal working hours in 
the time zones where most WebKit contributors live. I don't want to harp on 
this too much, since I don't personally disagree with the change, but if anyone 
does, then they may feel that they didn't really get a fair chance to comment.

Regards,
Maciej


On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote:

> Hi,
> 
> There is a patch posted for removal of the 'magic iframe' feature. This is 
> the ability to move 'live' iframe from one page to another w/o unloading it.
> If you have interest or ideas about this feature, please reply.
> 
> HISTORY
> This feature was added 2 years ago (bug here). It was intended as a shared 
> app context for complex apps that span several pages. In case when random set 
> of pages is closed, the surviving iframe could be passed between remaining 
> pages and serve as 'app state'.
> This behavior is somewhat described in HTML5 spec: "Removing an iframe from a 
> Document does not cause its browsing context to be discarded. Indeed, an 
> iframe's browsing context can survive its original parent Document if its 
> iframe is moved to another Document."
> All non-WebKit browsers don't have this and always unload the iframe when it 
> is disconnected form the document.
> 
> PROBLEMS
> We did have quite a few issues with this mechanism. The root of the problem 
> seems to be that traditionally, multiple 'permissions' and 'live objects' are 
> associated with a top-level page, or a top frame of some kind, instead of 
> being associated with each Frame. Even HTML specifications often formulate 
> the scope of things like permissions in terms of a page - for example, geo 
> permissions are computed based on the origin of the page. When an iframe is 
> transferred from one page to another, it may enter a different set of 
> permissions while already performing operations authorized before. 
> Association with the top-level page is also used to determine which one 
> should show modal UI for HTTP Auth, per-origin permissions, or certificate 
> issues for example.
> As a result, we had quite a few bugs popping up (and fixed).
> 
> WHY REMOVE
> This is somewhat obscure feature of the platform. Only a few apps that we 
> knew used the feature. Most developers, both app and webkit kind, don't even 
> know about it. When new mechanisms/APIs are implemented, a lot of objects get 
> associated with Page (WebView) level and they are almost 'automatically' 
> broken in case of live iframe transfer because once old page closes, it 
> destroys the objects with lifetimes scoped by it. This makes it somewhat 
> dangerous and difficult to support. The benefits that it gives to the big 
> multi-page applications do not seem to warrant the actual complexity of 
> maintaining this feature.
> Other browsers never implemented the feature, siting difficult design due to 
> various thorny security issues as well.
> 
> This is potentially a compatibility issue for sites that use 
> document.adoptNode(iframe) to ensure live transfer of an iframe from one page 
> to another.
> In the future, if there will be sufficient need, it is possible to design a 
> 'shared module' feature that would explicitly deal with various 
> security/lifetime boundaries.
> 
> Please let us know what you think.
> 
> Thanks,
> Dmitry
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Disabling Inspector on windows

[Vivek Galatage]

Hello webkit-dev,

I am trying to disable the inspector on windows port through issuing
following command -

./Tools/Scripts/build-webkit --no-inspector

But I think this command line switch is not considered by the build system
as I can see the code under ENABLE(INSPECTOR) is still enabled.

So any idea how to disable inspector feature on windows?

Thank you,
Vivek
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev