Re: [webkit-dev] to reitveld or not to reitveld

[John Abd-El-Malek]

On Mon, Jun 8, 2009 at 5:15 PM, Eric Seidel  wrote:

> At least one person has tried to tie review-board with bugzilla:
>
> http://www.visophyte.org/blog/2009/03/20/using-review-board-for-bugzilla-request-queues-reviews/
>
> I expect that we'd have to hack review board to do bugzilla-based
> authentication.  (Just like we'd have to hack rietveld to not run on
> AppEngine if we used it.)
>
>
> I agree with others that the rietveld authentication being tied to
> AppEngine and thus Google accounts is a show-stopper for WebKit.  I
> have no interest in creating yet another account and then worrying
> about whether I'm correclty logged into both bugzilla and webkit.org's
> google account in order to do patch reviews.  Currently I avoid
> dealing with chromium's tracker/review tool because every time I do I
> have to log out of my gmail.com google account so that I can log into
> my chromium.org google account. :(


AppEngine apps don't have to use Google Accounts for authentication.
 Rietveld has its own user-account layer, so it's possible to plug-in
different forms of authentication.


>
>
> -eric
>
> On Sat, Jun 6, 2009 at 7:44 PM, Ojan Vafai wrote:
> > On Sun, Jun 7, 2009 at 7:51 AM, Mark Rowe  wrote:
> >>
> >> On 2009-06-06, at 15:02, Peter Kasting wrote:
> >>
> >> On Sat, Jun 6, 2009 at 1:48 AM, Mark Rowe  wrote:
> >>>
> >>> Of the issues that Ojan mentioned in his original email, I see three
> that
> >>> would need to be addressed before we could consider adopting Rietveld:
> >>>
> >>> - Currently tied to AppEngine.
> >>
> >> I don't understand why this is problematic in the least, any more than
> >> saying "Bugzilla is currently tied to being run by Bugzilla".  Why does
> it
> >> matter what the backing implementation of Rietveld is?
> >>
> >> Primarily due to the two points that you trimmed from my email:
> >>
> >> Two other major issues jump out at me:
> >> - Authentication. This is related to the AppEngine tie-in.
> >> - Authorization.  Patch reviews need to reflect the access controls on
> the
> >> bugs that they are associated with.
> >>
> >> There are also concerns about access to the data store of the
> application,
> >> backup procedures, etc.  Our existing servers are well understood in
> this
> >> regard.   We've also found in the past that having services spread
> across
> >> different systems causes confusion when something goes wrong, for
> whatever
> >> reason, as it's not clear who to contact to address the problem.
> >
> > As I see it, these are the only non-trivial issues with using
> > rietveld. Things like not working with git are trivial fixes (e.g. git
> adds
> > "a/" and "b/" to the paths in the diff that need to be ignored). Also, I
> > really don't believe the intimidating UI is a problem in practice.
> Newcomers
> > get used to it very quickly.
> > I don't know enough about the rietveld code or appengine to say how
> > difficult it would be to address the authentication/authorization issues.
> > These would be the reason's to consider something like review-board
> instead.
> > My guess is that the access control bit is doable, but I think you'd
> > ultimately still need to sign in to AppEngine using a Google account.
> > For what it's worth, we've had next to zero maintenance effort go into
> > keeping rietveld running on appengine. As far as I know, it's been pretty
> > much stable and problem free. But I don't actually maintain it, so I
> can't
> > say that for sure. :)
> > Review-board would be considerably less effort than integrating something
> > directly into bugzilla. But rietveld would be less effort than
> review-board
> > if we can get the above issues addressed since there are a number of
> people
> > who already know the codebase willing to help out here.
> > It seems worth taking a look at how much work it would be to get
> > review-board setup and integrated with bugzilla.
> > Ojan
> > ___
> > 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] to reitveld or not to reitveld

[John Abd-El-Malek]

On Wed, Jun 10, 2009 at 8:12 AM, Joe Mason wrote:

> Mark Rowe wrote:
>
>> - UI is intimidating to newcomers.  This is clearly subjective, but since
>> the goal here is to make the review process friendlier, especially for new
>> contributors, I think it deserves calling out.
>>
> FWIW, after playing around with it for a few minutes I find its UI much,
> much friendlier than Bugzilla's itself.
>
> However, add me to the list for "not unless we can get seamless integration
> with the bug tracker and source control".  I think the biggest confusion for
> newcomers would be keeping track of the difference between the three tools,
> not learning how to use each one.  It doesn't matter to me whether this is
> achieved by actual deep integration with Bugzilla, or just passing data back
> and forth, as long as it feels like deep integration to the user.
>
> As a wild speculation: how hard would it be to build a new bug tracker by
> adding fields to Rietveld's issue descriptions, rather than trying to make
> changes to Bugzilla?  (A new bug report would simply be an issue without any
> patches uploaded yet.  We would need a space for general comments not tied
> to a line of code.  We'd need more metadata about each issue (component,
> priority, etc) and probably some new search and summary screens.  What else
> would be needed?)
>
> Add a CON for Rietveld: there's a surprising amount of overlap between
> computer terminology and the Rietveld method of crystallography, making it
> hard to sort out google results when looking for reviews of it.  Does
> anybody know of any unbiased third-party user stories that might help us
> evaluate the tool?
>
> Ojan or others who know the tool - can you explain a bit more about how it
> integrates with svn?


We use a script with Rietveld, gcl.py, that handles changelists.  It allows
you to have multiple changes on the same repository, each identified by a
name.  The script automates creation of a Rietveld issue when you first
upload.  It handles things like copied/moved/deleted/image files.


> I was under the impression that you just attach a patch, which could be
> from any source, but browsing
> http://code.google.com/p/rietveld/issues/list shows a few bug reports
> about svn integration that make it seem Rietveld is pulling more data from
> it (for instance, issue 82: ignores files created by svn cp, issue 100: fix
> for upload.py and svn with externals, and of course the eloquent issue 117:
> support cvs).  Would git integration mainly be a matter of making sure it
> parses git's patch output correctly?


>  Subjective, less important issues:
>> - I'm not sure about keeping patches and the bugs that they address in
>> separate systems.  It seems that discussion about a bug can end up split
>> between the two systems.
>>
> I don't think that's a minor issue at all.
>
>> - It's hard to spell.  Retyping it to fix the spelling makes me sad.
>>
> Agreed.  I expect will all end up calling it rfield soon enough (and I even
> typed that as rfiled the first time).
>
>> Ojan also mentioned ReviewBoard in his original email.  I've used it only
>> briefly, but I do know that it addresses some, but not all, of the issues
>> above (It's not tied to AppEngine, it works with both Subversion and Git,
>> and has some support for external authentication mechanisms).  It may
>> address others, but I've not looked closely enough to know for sure.
>>
> I'd like to hear some more comments on other code review systems.  Does
> anyone have any more in-depth comparisons with rfield?  Do they all use
> basically the same methodology with slightly different UI's, or are there
> major differences in approach?
>
> Joe
>
>
> ___
> 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] Windows Multithread issue

[John Abd-El-Malek]

Yes it's possible.  The Chromium port runs web views in different processes.
 You can look at the design docs and source to see how it's done, that
should give you an idea of what you have to do this on different threads.

2009/6/15 熊科浪 

>
> hi
> I want to develop c++ application that uses WebKit on Windows. Can I
> start a thread for each web view? or I must ceate every web view and handle
> every event in the main thread?and why?are there any plan to change it?
>
> Thank you.
>
> --
> clive
> --
> 立刻下载 MSN 保护盾，保障Messenger 安全稳定！ 现在就下载！ 
>
> ___
> 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] Windows Multithread issue

[John Abd-El-Malek]

Thanks for the info guys, I stand corrected.  Completely forgot about the JS
issue.

2009/6/15 Oliver Hunt 

> This is not possible due to various issues with the interaction between JS
> across multiple webviews, and the additional assumption that all layout and
> painting occurs in the UI thread.  Attempting to interact with WebKit on
> multiple threads will cause crashes.
> --Oliver
>
> On Jun 15, 2009, at 9:05 PM, 熊科浪 wrote:
>
>
> hi
> I want to develop c++ application that uses WebKit on Windows. Can I
> start a thread for each web view? or I must ceate every web view and handle
> every event in the main thread?and why?are there any plan to change it?
>
> Thank you.
>
> --
> clive
> --
> 立刻下载 MSN 保护盾，保障Messenger 安全稳定！ 现在就下载！ 
> ___
> 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-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[John Abd-El-Malek]

To add another tangent to this thread: one thing I don't like about
ChangeLog files is that they make it impossible to have multiple concurrent
changes in the same checkout.  Yes I know that some people use git to get
around this, while others use the svn-apply/svn-unapply scripts.  But I feel
these are just workarounds to get around limitations of the current tools.
 We should fix the tools instead.  If we don't require to change one central
file for each change, then bugzilla-tool can be modified to support
changelists.

On Thu, Jul 9, 2009 at 1:45 PM, Ojan Vafai  wrote:

> While having consistency in changelog descriptions is nice, I'm not sure we
> need to explicitly deal with the case of having multiple authors or multiple
> bugs for a change. Those are rare enough situations that it's fine for
> people to include that information however they want.
> Or, if you don't agree with me, we can at least make those a separate
> discussion. It would be nice if this discussion could focus on what goes in
> the default text of a changelog description.
>
> The original goal here was to reduce the number of patches that get r-'ed
> for unnecessary changelog errors. Multiple authors rarely, if ever, results
> in an r-. Similarly, multiple bugs is rarely an issue for new contributors.
>
> Ojan
>
> On Thu, Jul 9, 2009 at 1:30 PM, Mark Rowe  wrote:
>
>>
>> On 2009-07-09, at 08:02, Joe Mason wrote:
>>
>>  Maciej Stachowiak wrote:
>>>
 Now that my attention has been called to it, it's starting to bug me
 that everyone formats their ChangeLog entries slightly differently. How
 about this as the canonical format (with prepare-ChangeLog encouraging it)?

>>>
>>> That reminds me: how do we format a patch with multiple authors?  I've
>>> been doing this:
>>>
>>>  2009-07-08  Maciej Stachowiak  
   Make prepare-ChangeLog less shouty
   https://bugs.webkit.org/show_bug.cgi?id=27098

>>> > Authors: Maciej Stachowiak , Joe Mason <
>>> joe.ma...@torchmobile.com>
>>>
   Reviewed by Mark Rowe.
   * Scripts/prepare-ChangeLog:

>>>
>>> So, the main author (or whichever one is submitting the patch if that's
>>> unclear) in the header, then a separate "Authors" line above the Reviewer
>>> line with everyone who deserves credit.
>>>
>>
>> I've never seen this format used in WebKit patches.
>>
>> - Mark
>>
>>
>> ___
>> 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-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[John Abd-El-Malek]

The workflow I'm looking for is something like svn/perforce changelists.
 That way I could have multiple unrelated changes coexisting in the same
checkout.
An example of this is what we use on Chromium: gcl.py (see the latest
version at
http://src.chromium.org/viewvc/chrome/trunk/tools/depot_tools/gcl.py?view=markup).
 It allows you to create a changelist and associate a description and a list
of files/directory changes with it).  The basic usage is that "gcl
change CHANGENAME" pops up a text file in the default editor where a
description can be entered.  By moving filenames from two sections below it,
the developer controls which modified files are in this changelist.
 Operations such as "gcl upload CHANGENAME" (upload to Rietveld) work on the
group of files at the same time (also things like gcl
diff/commit/revert).  The nice thing about it that on such large codebases,
developers will often have unrelated changes, and this avoids having to
unapply/apply frequently.

On Fri, Jul 10, 2009 at 5:57 PM, David Kilzer  wrote:

> Quilt?  <http://savannah.nongnu.org/projects/quilt>
>
> What workflow are you trying to accomplish?  I'm not sure I understand what
> a "changelist" is in this context and how bugzilla-tool would support them.
>
> Dave
>
>
>
> *From:* John Abd-El-Malek 
> *To:* Ojan Vafai 
> *Cc:* WebKit Development ; Mark Rowe <
> mr...@apple.com>
> *Sent:* Friday, July 10, 2009 5:11:53 PM
> *Subject:* Re: [webkit-dev] Changes to prepare-ChangeLog
>
> To add another tangent to this thread: one thing I don't like about
> ChangeLog files is that they make it impossible to have multiple concurrent
> changes in the same checkout.  Yes I know that some people use git to get
> around this, while others use the svn-apply/svn-unapply scripts.  But I feel
> these are just workarounds to get around limitations of the current tools.
>  We should fix the tools instead.  If we don't require to change one central
> file for each change, then bugzilla-tool can be modified to support
> changelists.
>
> On Thu, Jul 9, 2009 at 1:45 PM, Ojan Vafai  wrote:
>
>> While having consistency in changelog descriptions is nice, I'm not sure
>> we need to explicitly deal with the case of having multiple authors or
>> multiple bugs for a change. Those are rare enough situations that it's fine
>> for people to include that information however they want.
>> Or, if you don't agree with me, we can at least make those a separate
>> discussion. It would be nice if this discussion could focus on what goes in
>> the default text of a changelog description.
>>
>> The original goal here was to reduce the number of patches that get r-'ed
>> for unnecessary changelog errors. Multiple authors rarely, if ever, results
>> in an r-. Similarly, multiple bugs is rarely an issue for new contributors.
>>
>> Ojan
>>
>> On Thu, Jul 9, 2009 at 1:30 PM, Mark Rowe  wrote:
>>
>>>
>>> On 2009-07-09, at 08:02, Joe Mason wrote:
>>>
>>>  Maciej Stachowiak wrote:
>>>>
>>>>> Now that my attention has been called to it, it's starting to bug me
>>>>> that everyone formats their ChangeLog entries slightly differently. How
>>>>> about this as the canonical format (with prepare-ChangeLog encouraging 
>>>>> it)?
>>>>>
>>>>
>>>> That reminds me: how do we format a patch with multiple authors?  I've
>>>> been doing this:
>>>>
>>>>  2009-07-08  Maciej Stachowiak  
>>>>>   Make prepare-ChangeLog less shouty
>>>>>   https://bugs.webkit.org/show_bug.cgi?id=27098
>>>>>
>>>> > Authors: Maciej Stachowiak , Joe Mason <
>>>> joe.ma...@torchmobile.com>
>>>>
>>>>>   Reviewed by Mark Rowe.
>>>>>   * Scripts/prepare-ChangeLog:
>>>>>
>>>>
>>>> So, the main author (or whichever one is submitting the patch if that's
>>>> unclear) in the header, then a separate "Authors" line above the Reviewer
>>>> line with everyone who deserves credit.
>>>>
>>>
>>> I've never seen this format used in WebKit patches.
>>>
>>> - Mark
>>>
>>>
>>> ___
>>> 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-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Changes to prepare-ChangeLog

[John Abd-El-Malek]

I don't want to open the can of worms that is git vs other source control
systems.  However given that the instructions for developing WebKit are for
svn and there already exists svn-apply/unapply scripts, I think there are
enough WebKit devs using svn that warrant improving this process flow.

On Wed, Jul 15, 2009 at 12:52 AM, Gustavo Noronha Silva wrote:

> On Fri, 2009-07-10 at 18:18 -0700, John Abd-El-Malek wrote:
> > this changelist.  Operations such as "gcl upload CHANGENAME" (upload
> > to Rietveld) work on the group of files at the same time (also things
> > like gcl diff/commit/revert).  The nice thing about it that on such
> > large codebases, developers will often have unrelated changes, and
> > this avoids having to unapply/apply frequently.
>
> This looks like a hack that is fixed by using a proper tool, such as
> git, to me.
>
> --
> Gustavo Noronha Silva 
> GNOME
>
> ___
> 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] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[John Abd-El-Malek]

On Wed, Sep 16, 2009 at 1:53 PM, Maciej Stachowiak  wrote:

>
> On Sep 16, 2009, at 11:23 AM, Geoffrey Garen wrote:
>
>  Given some of our (Chromium-team) recent investigation into the contents
>>> of unload handlers, I'm not sure how much this move will help users, even if
>>> you don't revert it.  Lots of unload handlers busy-wait while doing async
>>> XHR in order to try to guarantee delivery of tracking pings.  Authors will
>>> probably elect to copy this code to the pagehide handler rather than moving
>>> it, and the experience for users is still going to be extremely sluggish
>>> navigation out of these pages.
>>>
>>
>> While it's great that you've made improvements for unload handlers (or
>> maybe not-so-great, since you made them only in v8),
>>
>
Note I had sent an email to a few WebKit folks to see if they're interested
in doing this in JSC as well, but since I didn't hear back, I kept it in V8
only.


> I think a good way to deal with poorly written unload handlers is to
> temporarily set the slow script timeout to a much lower value during
> execution of unload. This would not require any JS-engine-specific changes
> to work.
>

I'm personally not a fan of the slow script dialog, as the average user
doesn't understand this enough to make a decision (i.e. they don't know if
they click this whether they'll lose data, they don't even understand what a
script is, etc).

Either way though, I don't think it'll work in this case.  I've seen pages
have 8 beforeunload/unload handlers each sleeping for 200ms, just so that
they don't have 1 handler that'll trip the slow script detection.  If we
decrease the timeout for unload handlers, they would just increase the
number of registered handlers proportionally.

>
> Regards,
> Maciej
>
> ___
> 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] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[John Abd-El-Malek]

On Wed, Sep 16, 2009 at 11:03 PM, Darin Fisher  wrote:

> On Wed, Sep 16, 2009 at 10:57 PM, Maciej Stachowiak  wrote:
>
>>
>> On Sep 16, 2009, at 10:33 PM, Darin Fisher wrote:
>>
>>
>>
>> On Wed, Sep 16, 2009 at 9:59 PM, Maciej Stachowiak  wrote:
>>
>>>
>>> On Sep 16, 2009, at 4:49 PM, Darin Fisher wrote:
>>>
>>>
>>>
>>> Counting work instead of time is much more robust.  The getTime call
>>> counts is a measure of work, albeit approximate.
>>>
>>>
>>> The way JavaScriptCore execution time limit works is that the clock
>>> doesn't start ticking until JS execution begins. So it's unlikely that a
>>> full timeout cycle will occur while the process is swapped out or paused,
>>> since the clock won't start running until the process is actually executing
>>> JS. And the actual timeout check is only done occasionally (every N loop
>>> back edges or function calls, for some value of N). So even if there's a
>>> context switch in the middle of JS execution, it's unlikely that JS
>>> processing will be terminated immediately upon return. So maybe a different
>>> solution is appropriate for JavaScriptCore than V8.
>>>
>>>
>> Consider what happens if during JS execution garbage collection runs.
>>  That could cause portions of the VM to be swapped into RAM, which could
>> cause significant wall clock delay.  Do you discount time spent in GC?
>>
>>
>> We don't exclude time spent in GC - slow is slow. But in practice we
>> haven't seen the scenario you describe come up under similar circumstances.
>>
>>
> This may be a bigger factor for Chrome since it is not uncommon for the
> renderer associated with a background tab to be swapped out.  If you just
> click the close button on a background tab, it is not uncommon for it to
> require some expensive paging :-(
>
>
>
>>
>> To help us decide whether (and how) to tackle this for non-V8 ports of
>>> WebKit, can the Chrome team share the data they have on the following:
>>>
>>> (1) Frequency of pages doing a busy loop in an unload handler. I've heard
>>> it's common but no specific data.
>>> (2) A few examples of URLs to pages that do this, so we can study what
>>> they are doing and why.
>>> (3) Frequency of a date-based loop being used to implement the busy loop.
>>> (4) Average additional delay imposed by unload busy loops.
>>> (5) Proportion of sites that use busy looping in unload solely for link
>>> tracking and not for any other purpose.
>>>
>>>
>> You can find links to example sites in the Chromium bug report:
>> http://code.google.com/p/chromium/issues/detail?id=7823
>>
>> The bug contains some distilled data.
>>
>>
>> I found a couple of URLs (which addresses #2) but I couldn't easily find
>> the other data I asked about. Will I find it if I carefully read all 80
>> comments on that bug, or should I assume it's not available?
>>
>>
> I'm not sure if everything you are looking for is spelled out in the bug.
>  Comment #46 has details for one such advertiser.  John may have some more
> distilled data.
>

I had used FireBug/Web Inspector to look into all the unload handlers on the
slow sites that are mentioned on the bug.  I posted some of the JS sleep
code, but not for all sites.  The ads served might have changed in the
meantime, which affects whether this code will be served or not.


>
>
>>
>> By the way, the issue is not with trouble sites but with trouble ad
>> networks and/or producers.  I believe the web sites are just victims here.
>>
>>
>>
>>> The reason I'm interested in (1)-(4) is to determine if doing nothing is
>>> really worse than doing something hackish, as suggested by Adam.
>>>
>>> The reason I'm interested in (5) is to determine if  is an
>>> adequate replacement. I think if we break existing techniques, we need to
>>> give authors a replacement. unload fires when the user leaves the page in
>>> any way whatsoever, including closing the window or typing in the location
>>> field. So sites could use I/O in unload plus a busy loop to track the amount
>>> of time the user spent on the page, or to save state. If sites are doing
>>> that, then  won't be an adequate replacement, so we'll have to do
>>> something like Adam's suggestion to guarantee completion of I/O that is
>>> initiated in the unload handler. The reason I think it's possible sites care
>>> about more than just link tracking is that if that's all they care about,
>>> they could just use redirect links, and get a better user experience today
>>> than busy looping in unload. If sites are not using redirects for link
>>> tracking today, why would they use  in the future?
>>>
>>>
>> The reason why I don't think they are using it for critical data is
>> because they have a timeout.  If they were trying to persist critical data
>> then they would just use a synchronous XHR.  In this case, they are trying
>> to increase the probability of successfully sending a ping by giving
>> themselves a few 100 ms.
>>
>>
>> I'm not saying it's necessarily critical data, just that I suspect they
>> may want 

Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[John Abd-El-Malek]

On Thu, Sep 17, 2009 at 2:09 PM, Darin Fisher  wrote:

>
>
> On Thu, Sep 17, 2009 at 12:52 PM, Maciej Stachowiak  wrote:
>
>>
>> On Sep 17, 2009, at 12:14 PM, Darin Fisher wrote:
>>
>>
>>
>> On Thu, Sep 17, 2009 at 2:28 AM, Maciej Stachowiak  wrote:
>>
>>>
>>> On Sep 17, 2009, at 12:35 AM, Darin Fisher wrote:
>>>
>>>

 For  to be used as I suggested, you would need to set the href
 to a javascript URL such as javascript:void(), so that it would not
 interfere with an existing navigation.

>>>
>>> Navigating to a javascript: URL will still cancel with an existing
>>> pending navigation, both per spec and in at least some browser engines
>>> (including WebKit). For spec reference see step 5 here: <
>>> http://dev.w3.org/html5/spec/Overview.html#navigate>. Note lack of
>>> exception for "javascript:" URLs.
>>
>>
>> nit: WebKit and most browsers that I tested _only_ do so if the
>> javascript: URL evaluates to a string. Take a look at
>> FrameLoader::executeIfJavaScriptURL().  I can also share my test case with
>> you if you are still doubting! ;-)
>>
>>
>> My test case did this from an onclick handler, and the navigation to
>> yahoo.com did not happen:
>>
>>  location.href="http://yahoo.com/";;
>>  location.href="javascript:void()";
>>
>>
> Yes, in that case the scheduled location change from the first href
> assignment is cancelled by the second.
>
> My test case was to dispatch a click event to an anchor tag during the
> unload handler.  Set the anchor's href to javascript:void() and notice that
> it does not interrupt the existing navigation.
>
>
>
>
>> It may be that other ways of navigating to a javascript: URL don't stop a
>> pending load, but that would be a bug.
>>
>
> I'm not sure.  It seems like each browser goes out of its way to only
> cancel the existing navigation when the javascript: URL results in a string.
>  Coincidence, really??
>
>
>
>>
>> Based on your comments below, I think the expedient thing to do is to let
>> Image loads (only) complete their I/O when initiated from unload or
>> pagehide.
>>
>
> Why exclude beforeunload?  Some of the sites we found use the busy loop
> hack in beforeunload.
>

These sites presumably did it to split the sleep calls across as many
handlers as possible to avoid hung script detectors.  If they rewrite their
pages to use one clean method, it seems they only need to do it in one
place.


>

> -Darin
>
>
>
>>
>>  - Maciej
>>
>>
>>
>>
>>>
>>>
>>>   I think it would also be necessary for the ping to be sent during the
 default event handler instead of when the href is normally processed.

>>>
>>> I'm not sure what you're suggesting, but link clicks are currently
>>> processed in the default event handler for HTMLAnchorElement.
>>
>>
>>
>> Sorry, I was thinking of the Mozilla implementation :-/
>>
>>
>>
>>>
>>>
>>>  As for guaranteeing completion of I/O started during unload, I am fairly
 concerned about the code complexity that would result from allowing some
 resource loads to go uncanceled at page navigation time.  Pings are
 different since they are fire and forget, but other resource loads, which
 normally get read and processed by the frame / loader system are a bit
 problematic to keep active.  We'd want to put them in a special mode where
 they don't get canceled but also don't get processed when their responses
 arrive.  There may be a clean way to do this, but I am concerned about the
 potential maintenance cost due to the extra mode for resource loading.

>>>
>>>
>>> Yes, it would be somewhat tricky, but the proposed  solution
>>> simply doesn't work. Even if there was a way to make it work, it would be
>>> pretty hard to use correctly, and not an intuitive choice.
>>>
>>
>> I agree that it is tricky, but that doesn't sound like much of a barrier
>> to the folks who would be using it.  I think people are desperate for
>> anything that works, and given that nothing really works today, they end up
>> with suboptimal hacks (e.g., busy looping).
>>
>>
>>
>>>
>>> Here's what would need to happen to let loads from unload run to
>>> completion:
>>>
>>> 1) Implement a way to track all entities that start loads during unload
>>> (all owners of ResourceHandles, say).
>>> 2) Add a way (perhaps via an abstract base class) for all such entities
>>> to release their ResourceHandle to another owner and then cancel themselves.
>>> 3) Add code after unload finishes to create an object that takes
>>> ownership of all these ResourceHandles, and stays alive until they all
>>> complete their loads (dropping results on the floor).
>>>
>>> I don't think this would be much harder than it would be to implement >> ping>. The only hard part really is #1, particularly making sure we've
>>> caught all possible kinds of resource loads.
>>>
>>
>> This does sound workable.  It might even be best to only start out
>> supporting Image requests.  That should make it easier to be confident in
>> the solution.  I wo

Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[John Abd-El-Malek]

On Thu, Sep 17, 2009 at 12:14 PM, Darin Fisher  wrote:

>
>
> On Thu, Sep 17, 2009 at 2:28 AM, Maciej Stachowiak  wrote:
>
>>
>> On Sep 17, 2009, at 12:35 AM, Darin Fisher wrote:
>>
>>
>>>
>>> For  to be used as I suggested, you would need to set the href to
>>> a javascript URL such as javascript:void(), so that it would not interfere
>>> with an existing navigation.
>>>
>>
>> Navigating to a javascript: URL will still cancel with an existing pending
>> navigation, both per spec and in at least some browser engines (including
>> WebKit). For spec reference see step 5 here: <
>> http://dev.w3.org/html5/spec/Overview.html#navigate>. Note lack of
>> exception for "javascript:" URLs.
>
>
> nit: WebKit and most browsers that I tested _only_ do so if the javascript:
> URL evaluates to a string. Take a look at
> FrameLoader::executeIfJavaScriptURL().  I can also share my test case with
> you if you are still doubting! ;-)
>
>
>
>>
>>
>>   I think it would also be necessary for the ping to be sent during the
>>> default event handler instead of when the href is normally processed.
>>>
>>
>> I'm not sure what you're suggesting, but link clicks are currently
>> processed in the default event handler for HTMLAnchorElement.
>
>
>
> Sorry, I was thinking of the Mozilla implementation :-/
>
>
>
>>
>>
>>  As for guaranteeing completion of I/O started during unload, I am fairly
>>> concerned about the code complexity that would result from allowing some
>>> resource loads to go uncanceled at page navigation time.  Pings are
>>> different since they are fire and forget, but other resource loads, which
>>> normally get read and processed by the frame / loader system are a bit
>>> problematic to keep active.  We'd want to put them in a special mode where
>>> they don't get canceled but also don't get processed when their responses
>>> arrive.  There may be a clean way to do this, but I am concerned about the
>>> potential maintenance cost due to the extra mode for resource loading.
>>>
>>
>>
>> Yes, it would be somewhat tricky, but the proposed  solution
>> simply doesn't work. Even if there was a way to make it work, it would be
>> pretty hard to use correctly, and not an intuitive choice.
>>
>
> I agree that it is tricky, but that doesn't sound like much of a barrier to
> the folks who would be using it.  I think people are desperate for anything
> that works, and given that nothing really works today, they end up with
> suboptimal hacks (e.g., busy looping).
>
>
>
>>
>> Here's what would need to happen to let loads from unload run to
>> completion:
>>
>> 1) Implement a way to track all entities that start loads during unload
>> (all owners of ResourceHandles, say).
>> 2) Add a way (perhaps via an abstract base class) for all such entities to
>> release their ResourceHandle to another owner and then cancel themselves.
>> 3) Add code after unload finishes to create an object that takes ownership
>> of all these ResourceHandles, and stays alive until they all complete their
>> loads (dropping results on the floor).
>>
>> I don't think this would be much harder than it would be to implement > ping>. The only hard part really is #1, particularly making sure we've
>> caught all possible kinds of resource loads.
>>
>
> This does sound workable.  It might even be best to only start out
> supporting Image requests.  That should make it easier to be confident in
> the solution.  I worry about supporting XHR since CORS makes for some
> complicated back-n-forth: not just a single ResourceHandle instance.
>
>
>
>>
>> Yet another possibility: we could introduce a Ping object or sendPing()
>> method that performs a ping without the need to follow a link, and
>> guarantees the I/O won't be cancelled due to navigation. That would localize
>> the need for added complexity. The downside is we'd have to either get it
>> into standards or do something WebKit-specific.
>>
>> A third possibility: limit unload persistence to Image and XMLHttpRequest,
>> to limit the complexity. That's assuming sites are not using scripts,
>> stylesheets or frames to do the exit ping - I don't know if that's a good
>> assumption.
>
>
> I think it is a good assumption.  Image is used today because of an IE
> *quirk* that causes it to not be cancelled upon page navigation.  Other ways
> of fetching subresources do not appear to be subject to that behavior.
>  However, I admit that I haven't personally studied IE enough to be certain.
>
> At any rate, I think I'm persuaded by your arguments.  Adam made a similar
> argument the other day too.  It seems reasonable to make Image behave this
> way when created in certain contexts.  We should probably include
> beforeunload and pagehide handlers since we have evidence that people do the
> same thing in beforeunload that they do in unload.  I include pagehide given
> the recent change to WebKit's page cache insertion policy.  We might even
> want to allow it in anchor tag click handlers for completeness.
>
> We should pr

Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[John Abd-El-Malek]

On Thu, Sep 17, 2009 at 4:08 PM, Maciej Stachowiak  wrote:

>
> On Sep 17, 2009, at 2:16 PM, John Abd-El-Malek wrote:
>
>
>>
>> I think the image trick is more attractive than  because it's
>> easier for web developers to use.  But I'm not convinced it's the cleanest
>> method we can come up with.  If we are expecting web developers to change,
>> then I'd prefer something more explicit link asyncPing(url).  The benefit is
>> that it doesn't tie up connection limits like image loading would, and hence
>> shouldn't impact the navigated page's loading.  The UA is then free to pick
>> the best time to do the ping, i.e. when network activity has died down.
>>
>>
> With the Image trick, web developers don't have to change, other than to
> get rid of the busy loop. I wouldn't be too averse to also adding an
> explicit  ping API, but it seems to me it's possible to do many of the
> optimizations you describe for the Image-in-unload trick.
>

Good points.  These were my biggest sticking point with the image trick, now
that I'm not concerned about them anymore, I really appreciate the
compatibility with IE that this gives.


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

Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[John Abd-El-Malek]

To resurrect this thread.  I'm looking in implementing some of the methods
that we discussed so that web developers have no excuse in simulating sleeps
in unload handlers.
>From this thread, the options that were discussed were
-: The pros were that it would work without JavaScript, and could be
disabled easily via an option like referral headers.   But given that it's
not possible for this to work in iframes in Firefox and perhaps other
browsers and that the users of the sleeps are ad networks using iframes, it
doesn't fit the requirements.
-window.sendPing(): elegant, but requires educating web developers.  also
required JavaScript to be enabled.
-Image trick (image loads started from unload handlers outlive the page):
simple, maintains comparability with IE and existing sites.  however a
little inelegant and requires JavaScript.
-allow XHR with a special flag, or ones started from unload handlers to
outlive the page: doesn't seem worth it since it involves both extra
complexity in WebCore, requires changing web sites, and doesn't have
compatibility with IE

In an ideal world, I would prefer window.sendPing.  Given the benefits of
maintaining compatibility with IE and existing sites, I do think the image
loading trick is the best solution at this point.  I've  gone back and forth
on this a few times, but at the end the limitations of  where it
does not work for iframes in other browsers render it useless.  Although the
image trick requires JavaScript, I think this is acceptable since the
problem sites now already use JavaScript to simulate sleeps and fetch the
image, so we're not placing more requirements on them.

Do we have agreement on proceeding with implementing the Image based
approach?

Thanks,
John

On Thu, Sep 17, 2009 at 6:26 PM, John Abd-El-Malek  wrote:

>
>
> On Thu, Sep 17, 2009 at 4:08 PM, Maciej Stachowiak  wrote:
>
>>
>> On Sep 17, 2009, at 2:16 PM, John Abd-El-Malek wrote:
>>
>>
>>>
>>> I think the image trick is more attractive than  because it's
>>> easier for web developers to use.  But I'm not convinced it's the cleanest
>>> method we can come up with.  If we are expecting web developers to change,
>>> then I'd prefer something more explicit link asyncPing(url).  The benefit is
>>> that it doesn't tie up connection limits like image loading would, and hence
>>> shouldn't impact the navigated page's loading.  The UA is then free to pick
>>> the best time to do the ping, i.e. when network activity has died down.
>>>
>>>
>> With the Image trick, web developers don't have to change, other than to
>> get rid of the busy loop. I wouldn't be too averse to also adding an
>> explicit  ping API, but it seems to me it's possible to do many of the
>> optimizations you describe for the Image-in-unload trick.
>>
>
> Good points.  These were my biggest sticking point with the image trick,
> now that I'm not concerned about them anymore, I really appreciate the
> compatibility with IE that this gives.
>
>
>>
>>  - Maciej
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[John Abd-El-Malek]

On Wed, Oct 14, 2009 at 7:53 PM, Maciej Stachowiak  wrote:

>
> On Oct 14, 2009, at 6:43 PM, John Abd-El-Malek wrote:
>
>  To resurrect this thread.  I'm looking in implementing some of the methods
>> that we discussed so that web developers have no excuse in simulating sleeps
>> in unload handlers.
>>
>
> ...
>
>  -Image trick (image loads started from unload handlers outlive the page):
>> simple, maintains comparability with IE and existing sites.  however a
>> little inelegant and requires JavaScript.
>>
>
> ...
>
>  Do we have agreement on proceeding with implementing the Image based
>> approach?
>>
>
> Yes, I think we should let image loads from unload handlers run to
> completion. I don't see much downside, and the compatibility with IE
> behavior is pretty compelling.
>
> The other ideas you mentioned don't seem as good. Making a new API or a new
> XHR flag would be WebKit-specific and thus inferior to the Image thing. And
> I think , though it may have its uses, does not apply to this use
> case. Dynamically creating an  element and sending it a fake click event
> is rather awkward. And navigations initiated from the unload handler do not
> actually happen. It would be weird to special-case things so that the ping
> is sent anyway, even though the navigation does not go through. Let's
> reserve  for hyperlink auditing and not bend it to the purpose of
> page close auditing.
>

Sounds good.  I'll start the image loading first, and then when I'm done I
can do .


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

Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[John Abd-El-Malek]

On Thu, Oct 15, 2009 at 12:31 AM, Darin Fisher  wrote:

> On Wed, Oct 14, 2009 at 7:53 PM, Maciej Stachowiak  wrote:
>
>>
>> On Oct 14, 2009, at 6:43 PM, John Abd-El-Malek wrote:
>>
>>  To resurrect this thread.  I'm looking in implementing some of the
>>> methods that we discussed so that web developers have no excuse in
>>> simulating sleeps in unload handlers.
>>>
>>
>> ...
>>
>>  -Image trick (image loads started from unload handlers outlive the page):
>>> simple, maintains comparability with IE and existing sites.  however a
>>> little inelegant and requires JavaScript.
>>>
>>
>> ...
>>
>>  Do we have agreement on proceeding with implementing the Image based
>>> approach?
>>>
>>
>> Yes, I think we should let image loads from unload handlers run to
>> completion. I don't see much downside, and the compatibility with IE
>> behavior is pretty compelling.
>>
>> The other ideas you mentioned don't seem as good. Making a new API or a
>> new XHR flag would be WebKit-specific and thus inferior to the Image thing.
>> And I think , though it may have its uses, does not apply to this
>> use case. Dynamically creating an  element and sending it a fake click
>> event is rather awkward. And navigations initiated from the unload handler
>> do not actually happen. It would be weird to special-case things so that the
>> ping is sent anyway, even though the navigation does not go through. Let's
>> reserve  for hyperlink auditing and not bend it to the purpose of
>> page close auditing.
>>
>> Regards,
>> Maciej
>>
>>
>
> I'm mostly convinced that we should implement the image hack.  I'm also
> convinced that  is best left for hyperlink auditing.
>
>  However, if we do implement  (and I think we should), it seems
> natural to also provide a scriptable way to produce a similar effect.
>  window.sendPing seems attractive for that reason.
>
> The way I look at it is, if a UA were to provide an option to disable
> pings, should that option impact the behavior of the image hack?  It is
> clear from the point of view of the web developer that  and
> window.sendPing would be effected, but it is less clear in the case of the
> image hack.  Maybe someone is using the image hack to prefetch images (a
> login screen might prefetch resources for what lies behind the login
> screen), which is a very different use case from sending pings.
>
> If we do not do window.sendPing, then it also means that some people may be
> tempted to create unload handlers just so that they can take advantage of
> the image hack to send pings for things like usage data, when they would
> otherwise just send the pings at their convenience (periodically perhaps).
>  That seems rather awkward to me and unfortunate since it would be nice if
> people didn't have to write unload handlers ;-)
>

Does this argue for making the image loading trick work all the time from
JS, not just from unload handlers?  I tested with IE and it looks like the
image trick works all the time, not just in unload handlers.  My test case
was to load the image in the onload handler and change document.location to
"about:blank" right after.  Firefox/Safari/Chrome didn't load the image most
of the time.

I see your points about window.sendPing.  I think it's the most elegant
solution.  But given that we'll allow the image trick for pragmatic reasons,
then it's not needed.  Shouldn't the bar for exposing methods be high, i.e.
only if there's no other way of doing this?


>
> Anyways, this is just a minor point.  Overall, I'm happy even if we only
> implement the image hack and .  It just seems like there is a
> reasonable case for window.sendPing.
>
> -Darin
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Limiting slow unload handlers (Re: Back/forward cache for pages with unload handlers)

[John Abd-El-Malek]

I've createdhttps://bugs.webkit.org/show_bug.cgi?id=30457 for the image
trick
https://bugs.webkit.org/show_bug.cgi?id=30458 for  and
window.sendPing

On Thu, Oct 15, 2009 at 3:56 PM, Darin Fisher  wrote:

> On Thu, Oct 15, 2009 at 1:53 PM, Peter Kasting wrote:
>
>> On Thu, Oct 15, 2009 at 1:50 PM, John Abd-El-Malek wrote:
>>
>>> Does this argue for making the image loading trick work all the time from
>>> JS, not just from unload handlers?  I tested with IE and it looks like the
>>> image trick works all the time, not just in unload handlers.  My test case
>>> was to load the image in the onload handler and change document.location to
>>> "about:blank" right after.  Firefox/Safari/Chrome didn't load the image most
>>> of the time.
>>>
>>
>> This would mean normal pages that are still loading would keep loading all
>> their images after navigation, wouldn't it?  Bad.
>>
>
> Right.  For this reason, limiting it to just unload handlers seems best.
>  It is unlikely that images created during unload would be for anything
> other than pings.
>

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

[webkit-dev] prepare-Changelog crashing on cygwin

[John Abd-El-Malek]

After reimaging my Windows 7 machine, prepare-Changelog always crashes for
me now.  It seems to have problems running "svn diff".  I installed cygwin
through the installer on webkit.org.  I don't have any anti-virus programs
running, and DEP is turned off for cygwin.exe and svn.exe.  Has anyone else
seen this?

Thanks,
John


jabdelma...@jabdelmalek0-w /cygdrive/d/WebKit/WebKit/chromium
$ ../../WebKitTools/Scripts/prepare-ChangeLog
  Running status to find changed, added, or removed files.
?   svn.exe.stackdump
  Reviewing diff to determine which lines changed.
  0 [main] svn 1652 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   1873 [main] svn 1652 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 1652 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   1873 [main] svn 1652 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 7828 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
  0 [main] svn 7828 exception::handle: Exception:
STATUS_ACCESS_VIOLATION   1863 [main] svn 7828 open_stackdumpfile: Dumping
stack trace
 to svn.exe.stackdump

   1863 [main] svn 7828 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 6132 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   1818 [main] svn 6132 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 6132 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   1818 [main] svn 6132 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  1 [main] svn 15284 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   1547 [main] svn 15284 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  1 [main] svn 15284 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   1547 [main] svn 15284 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 9296 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   2474 [main] svn 9296 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump

   2474 [main] svn 9296 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 10444 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   2067 [main] svn 10444 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 10444 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   2067 [main] svn 10444 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 12428 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   1925 [main] svn 12428 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 12428 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   1925 [main] svn 12428 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 3940 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
  0 [main] svn 3940 exception::handle: Exception:
STATUS_ACCESS_VIOLATION   1538 [main] svn 3940 open_stackdumpfile: Dumping
stack trace
 to svn.exe.stackdump

   1538 [main] svn 3940 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 15008 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   2251 [main] svn 15008 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump

   2251 [main] svn 15008 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 14496 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   1796 [main] svn 14496 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
  0 [main] svn 14496 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
   1796 [main] svn 14496 open_stackdumpfile: Dumping stack trace to
svn.exe.stackdump
exec of 'diff' failed: Bad addresssvn: 'diff' returned 255
  Extracting affected function names from source files.
  Change author: John Abd-El-Malek .
  Running 'svn update' to update ChangeLog files.
At revision 59081.
  Editing the ./ChangeLog file.
-- Please remember to include a detailed description in your ChangeLog
entry. --
-- See <http://webkit.org/coding/contributing.html> for more info --
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] prepare-Changelog crashing on cygwin

[John Abd-El-Malek]

btw, I finally solved this.  credit to tonyg:

1) close cygwin
2) C:\cygwin\bin>ash rebaseall

On Mon, May 10, 2010 at 12:20 PM, Eric Seidel  wrote:

> On Mon, May 10, 2010 at 11:31 AM, Eric Seidel  wrote:
> > I have seen this on the win-ews ec2 instance.
> >
> > On May 10, 2010 1:35 PM, "John Abd-El-Malek"  wrote:
> >
> > After reimaging my Windows 7 machine, prepare-Changelog always crashes
> for
> > me now.  It seems to have problems running "svn diff".  I installed
> cygwin
> > through the installer on webkit.org.  I don't have any anti-virus
> programs
> > running, and DEP is turned off for cygwin.exe and svn.exe.  Has anyone
> else
> > seen this?
> >
> > Thanks,
> > John
> >
> > jabdelma...@jabdelmalek0-w /cygdrive/d/WebKit/WebKit/chromium
> > $ ../../WebKitTools/Scripts/prepare-ChangeLog
> >   Running status to find changed, added, or removed files.
> > ?   svn.exe.stackdump
> >   Reviewing diff to determine which lines changed.
> >   0 [main] svn 1652 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >1873 [main] svn 1652 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 1652 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >1873 [main] svn 1652 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 7828 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >   0 [main] svn 7828 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION   1863 [main] svn 7828 open_stackdumpfile:
> Dumping
> > stack trace
> >  to svn.exe.stackdump
> >1863 [main] svn 7828 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 6132 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >1818 [main] svn 6132 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 6132 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >1818 [main] svn 6132 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   1 [main] svn 15284 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >1547 [main] svn 15284 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   1 [main] svn 15284 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >1547 [main] svn 15284 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 9296 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >2474 [main] svn 9296 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >2474 [main] svn 9296 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 10444 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >2067 [main] svn 10444 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 10444 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >2067 [main] svn 10444 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 12428 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >1925 [main] svn 12428 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 12428 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >1925 [main] svn 12428 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 3940 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >   0 [main] svn 3940 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION   1538 [main] svn 3940 open_stackdumpfile:
> Dumping
> > stack trace
> >  to svn.exe.stackdump
> >1538 [main] svn 3940 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 15008 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >2251 [main] svn 15008 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >2251 [main] svn 15008 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 14496 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >1796 [main] svn 14496 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stackdump
> >   0 [main] svn 14496 exception::handle: Exception:
> > STATUS_ACCESS_VIOLATION
> >1796 [main] svn 14496 open_stackdumpfile: Dumping stack trace to
> > svn.exe.stac

Re: [webkit-dev] SharedWorkers alternate design

[John Abd-El-Malek]

On Fri, May 22, 2009 at 2:50 PM, Jeremy Orlow  wrote:

> On Fri, May 22, 2009 at 2:25 PM, Drew Wilson  wrote:
>
>> Following up on this, I had a question about the best way to enable the
>> implementation of SharedWorkerRepository to vary for different platforms.
>> I'd like to provide a default WebKit implementation, but on Chromium we'll
>> want to provide an implementation that proxies shared worker operations to
>> the browser process - it is unlikely that the two implementations will share
>> very much (any?) code.
>>
>> The current design just defines SharedWorkerRepository as an interface,
>> then has a platform-specific static factory which returns an instance of
>> this class - the idea is that I'd provide a default WebKit implementation
>> (called SharedWorkerProxyImpl.cpp?), then Chromium (or other platforms that
>> want their own implementation) can provide their own factory method and
>> implementation (for an example of this, see WorkerContextProxy::create() in
>> WebCore/worker/WorkerMessagingProxy.cpp.
>>
>> Is this an acceptable approach? Other approaches I've seen either scatter
>> ifdefs around in header files (see KURL.h for an example) which seems
>> non-ideal for our case which won't have any shared code, or to have separate
>> platform-specific subdirectories, but I'm not certain what the naming
>> convention is for a directory that contains "> but chromium>".
>>
>> I think the interface + static factory approach is the cleanest,
>
>
> This is the gist of what I'm planning for LocalStorage and I believe what
> Michael's planning for AppCache.  At least in my case, I think I'll be able
> to share a substantial amount of code by running the backend of the code in
> the chromium browser process.
>

I also agree this is the cleanest approach.  Especially for these kind of
objects (workers, storage) that aren't created or called that frequently,
the memory and performance overhead is negligible.  One other benefit is
that it allows platforms to both define their own implementations and to use
the default WebKit implementation.

>
>
>
>> but I've gotten the impression that the use of virtual functions to vary
>> implementations per-platform is frowned upon in WebKit. Any advice for me?
>>
>> -atw
>>
>>
>>
>>
>> On Fri, May 22, 2009 at 1:20 PM, Kenneth Christiansen <
>> kenneth.christian...@openbossa.org> wrote:
>>
>>> I believe Qt uses instance() in this situation.
>>>
>>> > Sadly we have not yet found a good verb for the common "get or create"
>>> > idiom.
>>>
>>> Cheers.
>>> Kenneth
>>>
>>
>>
>> ___
>> 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-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

[John Abd-El-Malek]

I agree that this approach is powerful.  However there are (not too
frequent) situations when a port like Chromium wants to use both the WebKit
implementation and its own implementation, switching in runtime.  For
workers, this happened with WorkerContextProxy/WorkerObjectProxy which are
the interfaces that a worker object implements/uses.  Since workers run in a
separate process from the renderer, we use our own implementations of these
interfaces that know about IPC etc.  However once we're in the worker
process, we want to run nested workers in the same process, in which case we
want to use the WebKit implementation of these interfaces directly without
using Chromium's.
Chromium doesn't have this use case for SharedWorkerRepository, so it
doesn't need to be an interface if that's more consistent with WebKit code.
 Apology for the wrong suggestion Drew :)

On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak  wrote:

>
> On May 26, 2009, at 10:21 AM, Darin Adler wrote:
>
>  On May 26, 2009, at 10:16 AM, Drew Wilson wrote:
>>
>>  OK, I've got two strong votes for the interface + static factory
>>> approach. Any objections from the rest of the WebKit team? If I don't hear
>>> any counter proposals, I'll do that.
>>>
>>
>> I think it's unpleasant to pay run-time cost for a compile-time choice.
>> Sure, sometimes the extra cost is no big deal, but sometimes it can be a big
>> deal and I see no reason to choose idioms that use virtual functions if
>> there are equally good or better ones that don't.
>>
>> Are there really no better techniques than abstract base classes and
>> virtual functions for this sort of compile-time switch? How about the
>> technique used for ResourceRequest and ResourceResponse? Maybe Darin Fisher
>> can explain that one.
>>
>
> I agree with Darin's comments here. We've tried hard to avoid using runtime
> polymorphism for compile-time choices. Here it's probably not
> performance-critical, but it can be avoided.
>
> The ResourceRequestBase / ResourceRequest model (due to Darin Fisher) seems
> pretty clean to me. I would like to see more of our classes with
> port-specific implementation details move to this style. I think it could
> work for SharedWorkerRepository.
>
> The basic idea is this. Let's say you have a class FooBar.
>
> - You define a FooBarBase class that has the cross-platform interface and
> data members. But not all the methods are actually implemented in the
> cross-platform code. All of its constructors are protected so the class
> cannot be instantiated directly.
> - Each port subclasses FooBarBase to define FooBar, adding constructors,
> platform-specific data members, and any needed platform-specific private
> helpers or type conversions.
> - Each port implements the methods of FooBarBase that are
> platform-specific, freely downcasting to FooBar when needed since we have
> guaranteed that every instance of FooBarBase is actually a FooBar.
> - Cross-platform code using the class just uses FooBar. The Base class is
> an implementation detail.
>
> (Darin F., please correct me if I have not done justice to this technique.)
>
> Note that this method has no runtime cost - there's no need to use virtual
> methods or other forms of runtime indirection. And there's no need to #ifdef
> any headers, everything is controlled purely by including the right platform
> specific FooBar.h so it can be handled by include paths. It's a little
> subtle at first but I think it results in nice, understandable code.
>
> I think we should document this technique as the preferred way to make
> classes with port-specific implementation details and convert more of
> WebCore/platform/ to this technique, as well as using it for new classes.
>
> Regards,
> Maciej
>
>
> ___
> 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] SharedWorkers alternate design

[John Abd-El-Malek]

On Tue, May 26, 2009 at 5:00 PM, Sam Weinig  wrote:

> On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek wrote:
>
>> I agree that this approach is powerful.  However there are (not too
>> frequent) situations when a port like Chromium wants to use both the WebKit
>> implementation and its own implementation, switching in runtime.  For
>> workers, this happened with WorkerContextProxy/WorkerObjectProxy which are
>> the interfaces that a worker object implements/uses.  Since workers run in a
>> separate process from the renderer, we use our own implementations of these
>> interfaces that know about IPC etc.  However once we're in the worker
>> process, we want to run nested workers in the same process, in which case we
>> want to use the WebKit implementation of these interfaces directly without
>> using Chromium's.
>
>
> This doesn't seem like a runtime choice, but rather a "use-time" choice.
>  In the main context, you want use one implementation and in the worker
> context, another one.  This to me implies two different objects with
> different names.
>

The code that deals with these objects doesn't (and shouldn't) need to know
the difference, i.e. there is only one set of JavaScript bindings for
workers, regardless of which process they're being used in.


>  In non-multiprocess implementations of WebKit, these two objects could be
> the same object, and in multiprocess implementations (such as Chromium),
> they could be backed by different objects.  This would not incur a runtime
> cost (and would be, subjectively of course, clearer).
>
> -Sam
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

[John Abd-El-Malek]

On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow  wrote:

> On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow  wrote:
>
>> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig  wrote:
>>
>>> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow wrote:
>>>
 The common case is definitely that we know whether we want the proxy
 (for IPC) or the implementation at compile time.  In some cases (like
 Chromium) this is not known until initialization time.
>>>
>>>
>>>  What do you mean by "initialization time"?  Is it the case that you know
>>> which one you want at each call site?  Or do literally want to make a
>>> runtime choice based on state?
>>>
>>
>> Well, I meant that we always want one or the other based on if the process
>> is being used as a render process (i.e. sandboxed, running WebKit but with
>> all DOM Storage calls proxied) or a browser process (i.e. running only
>> selected parts of WebCore like the DOM Storage backend/implementation).
>>
>>
>> Come to think of it (IIRC) all calls to the StorageBackend within the
>> WebCore code should go through a proxy for Chromium.  The proxy will then
>> call into Chromium's webkit bridge/glue, which will pass the message through
>> the IPC layer, which will call back into bridge/glue code, which will be
>> interacting with the real implementation.
>>
>> If that's true, then the implementation could be very explicitly split
>> into 2 (with frontend code calling backend proxy code and vice versa) and
>> single process implementations could simply typedef _Proxy to _Impl
>> (or Implementation, or Base, or whatever you want to call it).
>>
>> or have I completely confused myself?
>>
>
> To clarify, I'm saying that your question made me realize that we probably
> can make a hard split between the frontend and backend code (i.e. what would
> live in a sandbox and handle page rendering and what wouldn't live in a sand
> box and store the actual DOM Storage data).  In single process cases where
> there is no IPC barrier, and thus no proxy (and thus the actual
> implementation code should be called directly) a typedef should bridge the 2
> with no run time performance penalty.
>
> Darin, Sam, Maciej: does this alleviate your concerns?
>
> Michael, Drew, John: do you think it'd work for workers/appcache as well?


This will work fine for appcache and localstorage, but isn't sufficient for
workers since the same caller gets different objects depending on which
process this is running in.  This doesn't happen for appcache and
localstorage.


>
>
> Everyone: have I completely missed something here?
>
> J
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

[John Abd-El-Malek]

On Wed, May 27, 2009 at 12:00 AM, Jeremy Orlow  wrote:

> On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak  wrote:
>
>>
>> On May 26, 2009, at 6:11 PM, Jeremy Orlow wrote:
>>
>>
>>> Did you say partly because it's more complicated than just splitting one
>>> class (and only having 1-way sync communication)?  If so, then we're still
>>> on the same page, because that's what I'll be doing as well.  I was just
>>> using the StorageBackend as an example, but events will require signals from
>>> the backend to the frontend, and some abstractions (like StorageArea) make a
>>> lot of sense whether or not things are split into two pieces, which sounds a
>>> lot like what you described with ResourceHandle.
>>>
>>
>> As a side note - I think it would be cool if we used more specific names
>> than "Backend" and "Frontened" in the actual code, since which end is front
>> and back is not always obvious nor always agreed upon by all observers. I
>> like Proxy and Impl ok as name pairs, not sure if that's the same
>> relationship you have in mind.
>
>
> I somewhat disagree regarding the terms frontend and backend being
> confusing.  It seems to me that the backend is always further away from the
> user than the frontend.  Same thing with client and server.  That said, I've
> definitely heard complaints about terms like this before (on other
> projects), so I'm not married to the terms.
>
> The names I was planning to use were outlined in a design doc I sent to
> this list (http://docs.google.com/View?id=dhs4g97m_8cwths74m).  Basically,
> I was planning to the term Backend, but the rest of the names are more
> descriptive.  If you have another suggestion for Backend, I'd be happy to
> change it.  I would have already, but the only other idea I had was server,
> and I think people find that term even more confusing.  StorageRepository
> might be an ok name.
>
> As for Impl and Proxy, they are actually somewhat orthogonal to the
> frontend and backend.  For example, if a script calls
> window.localStorage.setItem(foo, bar), the frontend in the render process
> will access the backend proxy which will send the message to the browser
> process where the backend implementation lives.  The backend implementation
> will then access the EventManagerProxy which will distribute the events to
> the EventManagerImpl in all the render processes.  In other words, Proxies
> are necessary anywhere messages originate.
>

Just as a data point: Chrome uses Proxy/Impl naming for a variety of classes
(i.e. WebWorkerProxy/WebWorkerImpl,
WebWorkerClientProxy/WebWorkerClientImpl, WebPluginProxy/WebPluginImpl,
WebPluginDelegateProxy/WebPluginDelegateImpl).  The code is also moving to X
and XClient for the two-way API for feature X.  If possible, it would be
good to match these names for the sake of consistency.

How about:

StorageImpl (lives in the process that opens the database)
StorageProxy (in multi-process browser, lives in the renderer process and
notifies above)

StorageClientImpl (receives event that value changed)
StorageClientProxy (in multi-process browser, lives in the browser process
and notifies above)


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