[webkit-dev] The "WebCore/platform/" directory situation

[David Hyatt]

After working for a while on the WebCore/platform/ directory, it's  
become clear that people don't really know what this directory is  
supposed to contain (and by people I mean pretty much everybody, both  
inside and outside Apple).  The purpose of the platform/ directory is  
to serve as a foundation library for WebCore.  It provides a widget  
toolkit, graphics primitives, basic data structures and wrappers  
around low level OS services.  It should not depend on any other parts  
of WebCore, but can depend on JavaScriptCore/wtf.


When considering whether or not to put code in platform/, you need to  
pretend like platform/ is a separate library.  If you find yourself  
needing files from page/ or rendering/, then you have two options:
	(a) Build an abstract interface that lets you communicate with the  
rest of WebCore (ScrollbarClient, HostWindow are examples of such  
interfaces)

(b) Put your file in page/ or somewhere else instead.

As the people who built the primary port that has been used as a  
reference (Windows) by the other ports, those of us at Apple have  
actually been the worst offenders at violating the layering  
abstraction!  We plan to start setting a better example here.  After  
all, if we violate our own layering all over the place in the Mac and  
Windows ports, then the rest of you will too.


I think for a long time, we've been saying "It's ok, I'll just dump it  
in here for now and worry about fixing it later," and that needs to  
stop.  From now on, when reviewing code that is modifying platform/,  
check for any new abstraction violations, and DO NOT let the person  
off the hook in a review.  Modifying code that is already in violation  
seems fine, but don't let people introduce additional new dependencies  
that will just have to be cut later.


"Other files in platform/ do it." can't be an excuse any more.

In my experience fixing ScrollView, I've found that taking the time to  
create a clean separation has actually resulted in a net drop in lines  
of code, fewer methods bridging over to WebKit, and more cross- 
platform sharing (and a whole lot of build bustage, but s, let's  
forget about that part).  There are other files that would similarly  
benefit from such a refactoring.


In some cases the files are probably just misplaced and should be  
moved to page/.


I am going to start filing bugs on these layering violations.  I  
encourage others to get involved with looking for problems in  
platform/ and filing bugs on these issues.


https://bugs.webkit.org/show_bug.cgi?id=21354 is a tracking bug for  
platform/ problems.  You can add any bugs you file as blocking it.


I also think it would be worthwhile to discuss options for preventing  
these layering violations from occurring going forward.  We need to  
make these violations impossible.  I'd love to hear suggestions on  
that front (separate library, hacked include paths, etc.).  Whatever  
we decide should be implementable by Mac, Win, Gtk, Qt, wx and  
Chromium, since we don't want platform-specific code in platform to  
violate layering either.


Thanks,
dave
([EMAIL PROTECTED])
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] gjs and WebKit

[Anton Nonko]

Hello,

Is it in plans to include gjs to WebKit? If it is, what would gjs look 
like in perspective? Will it be full GObject equivalent of 
JavaScriptCore API (contain GObject bindings of JSContextRef, 
JSObjectRef, et c.)? Or it won't differ much from current state?

-- 
Best regards,
Anton


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

Re: [webkit-dev] High Resolution Timer API proposal(s)

[Maciej Stachowiak]

On Oct 3, 2008, at 10:09 AM, Mike Belshe wrote:

> I'm not opposed to any of this; and the new API is definitely  
> nicer.  I'll bring up a devil's advocate point.  One thing I hate is  
> the Microsoft-style smorgasboard of APIs.  When you want to start a  
> timer, you have 6 to choose from, and I hope we can avoid similar  
> problems in the DOM.

Minor philosophical digression that I thought of after the fact. One  
of the things I found most unpleasant about Win32 APIs compared to Mac  
OS X and other Unix-like systems is the fact that so many seemingly  
basic calls take so many parameters. And that many of the parameters  
are often structs filled with many mysterious fields, and pointers to  
other structs. That makes figuring out how to do even the most basic  
thing a mystery.

On Mac OS X (from Cocoa to the BSD layer on down), this kind of  
parameteritis is rare, and the same is true of the Web platform. I  
find Cocoa development and Web development more fun than win32  
development, and I think I am not alone in feeling that way. So I fear  
parameteritis more than multiple functions with similar effects.

Regards,
Maciej

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

Re: [webkit-dev] Proposed Timer API

[George Staikos]

On 3-Oct-08, at 3:01 AM, Cameron McCormack wrote:

> Hi Maciej.
>
> Cameron McCormack:
>>> If possible, it would be nice if there could be some degree of
>>> compatibility between this proposed API and the one in SVG Tiny 1.2:
>>>
>>>  http://dev.w3.org/SVG/profiles/1.2T/publish/ 
>>> svgudom.html#svg__SVGTimer
>
> Maciej Stachowiak:
>> I considered that, but I don't like the fact that it makes the common
>> zero-delay continuation callback case into three lines of code  
>> instead
>> of one, for what I think is no practical benefit.
>
> Justin’s proposed API seems to need four lines for that case:
>
>   var t = new Timer();
>   t.repeatCount = 1;

Just curious - does that mean "repeat once" or "fire once"?   
Seems ambiguous on first glance.

I like Maciej's simple proposal better.

--
George Staikos
Torch Mobile Inc.
http://www.torchmobile.com/

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

[Rob Burns]

Hi Geoff,

On Oct 3, 2008, at 9:04 PM, Geoffrey Garen wrote:

>> Again, I'm wondering how many legitimate uses are there for short  
>> timeouts in background tabs/windows.
>
> In a background window:
> animation
> video

For animation and video, is it necessary even in a completely obscured  
view?

> audio

I only meant to discuss javascript here. Are authors spinning audio  
using javascript setTimeout (I ask naïvely)?

> work queues for database or other background processing

I think this is another example where event listeners or another  
approach entirely would be more legitimate than using timers. Are you  
talking about using setTimout to repeatedly poll to find out if a  
worker is finished? If so, this is definitely not the type of use we  
should facilitate long-term for script timers. Again, exploring these  
questions may lead us to a need to define other events that can  
trigger scripts to run (rather than reliance on polling).

> something interesting the web hasn't invented yet

Given the need to reign in the abuses I don't find this too  
compelling. We wouldn't be preventing innovations, just restricting  
those innovations to run in unburied web pages.

> To give you some context, Safari used to throttle plug-in timers for  
> background windows. The result was that users would see randomly  
> choppy content.

I'm more referring to pages that are completely buried and obscured so  
pages with no need not run at all and users would have no way to know  
they are running choppy.

> In a background tab:
> audio

Again is this being done with javascript? Anyway, I don't think it is  
much to ask of users that they keep tabs unburied to enable listening  
to the embedded audio (or otherwise for browsers to provide an  
interface to re-enable audio within those buried tabs). So authors and  
users do not already have any ingrained preconceptions that audio must  
play even if a tab is buried (and so need to tailor APIs for authors  
to micro-manage this).

> work queues for database or other background processing
> something interesting the web hasn't invented yet

See above.

> Also note that protections for background windows and tabs wouldn't  
> solve the majority of the problem we've seen in the wild, which is  
> the *foreground* window going crazy in a single-tabbed browsing  
> session.

I feel completely the opposite about this. If a foreground window is  
going crazy, that's a problem but a visible problem that even a novice  
user may know how to correct (if it even needs correcting).

However, finding one or a dozen background tabs (amidst tens or  
hundreds) where those tabs contain needlessly running timers (in both  
javascript and elsewhere) is a huge power drain and one whose impacts  
are difficult to access. For mobile users the problem is more obvious,  
but even for desktops, how much wasted energy goes into these cycles  
when repeated across millions (billions?) of processors world-wide  
(and then the air-conditioning that also goes into compensating for  
that needless heat generation)[1]?

Take care,
Rob

[1]: A bit off-topic: say a processor pegged at 20w churns away at  
these wasteful web app cycles for 2 hours each day driving the  
processor from an average of 10% power consumption to 99% power  
consumption. That's 17.8 power dissipation dedicated just to the  
needless cycles or 35.6 w-h energy consumption per day. For one  
billion computers that's 17.8 thousand MW or  35.6 thousand MW-h per  
day or 9256 thousand MW-h per work year. Avoiding something like 17.8  
thousand wasted MW power dissipation (and 9256 thousand MW-hours of  
energy) eliminates the need for dozens of nuclear / coal power  
reactors worldwide (or even dirtier peaker power plants). Considering  
a 1.341 pounds of CO2 per kilowatt-hour (the 1999 estimated rate so  
over-optimistic for world-wide electricity production) that's 12,412  
pounds per year. At 10¢ a kw-h that's $925 million per year in world- 
wide electricity expenses. And that's without calculating compensating  
cooling power consumption, both internal and external to the computing  
device. There's a lot of power (and potential power wasted) in the  
hands of browser developers.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposed Timer API

[Maciej Stachowiak]

On Oct 3, 2008, at 2:47 PM, Chris Marrin wrote:

>
>
> I think the reason you don't see the pattern of deferred timer  
> triggering is because today you just can't do it. I think the use  
> case I described (triggering a timer on an animation or media event)  
> will be common if and when we have that ability.

You can do it by passing around the relevant timer parameters  
separately (in an array or ad-hoc dictionary object) - this does not  
appear to be done very often.

>
> In the above example, does the system guarantee that starting a  
> timer and immediately stopping it will not ever fire that timer?

Yes.

> I can't imagine that guarantee being possible, especially for very  
> short (or zero) duration timers. If an implementation chooses to  
> queue up timer events as soon as they time out (plus the  
> optimization that zero duration timers would immediately queue),  
> they would have to dig into that queue and rip out any timers that  
> are stopped.

I don't know about a hypothetical implementation, but in WebKit's  
implementation of timers it would work fine and would not be at all  
difficult. We have a priority queue and skip stopped timers when  
pulling ones that have passed their fire date out of the queue. You  
have to do that correctly anyway, even for the old school setTimeout/ 
cancelTimeout APIs.

> And that might not even be desirable in many cases. What should  
> happen when a timer times out while a JS function is running and you  
> stop it? Should its event still run.

No it should not.

> I'm sure there are many interesting race conditions possible here.

There aren't multiple threads involved, so no possibility of race  
conditions.

> It seems like you would avoid these issues if you could have a param  
> to startTimer (or a separate createTimer function) that prevented  
> the timer from starting in the first place.

I think a createTimer function would not ease implementation in any  
way. Its only purpose would be a minor convenience to authors who want  
to create a timer that is not initially running. It is not clear to me  
if this is a common enough use case.

Regards,
Maciej

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

Re: [webkit-dev] Proposed Timer API

[Chris Marrin]

On Oct 3, 2008, at 1:48 PM, Maciej Stachowiak wrote:
>
> On Oct 3, 2008, at 11:01 AM, Chris Marrin wrote:
>
>>
>> On Oct 2, 2008, at 6:13 PM, Maciej Stachowiak wrote:
>>>
>>> On Oct 2, 2008, at 6:01 PM, Cameron McCormack wrote:
>>>
 Hi Maciej.

 Cameron McCormack:
>> If possible, it would be nice if there could be some degree of
>> compatibility between this proposed API and the one in SVG Tiny  
>> 1.2:
>>
>> http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#svg__SVGTimer

 Maciej Stachowiak:
> I considered that, but I don't like the fact that it makes the  
> common
> zero-delay continuation callback case into three lines of code
> instead
> of one, for what I think is no practical benefit.

 Justin’s proposed API seems to need four lines for that case:

 var t = new Timer();
 t.repeatCount = 1;
 t.addEventListener('timercomplete', function() { … }, false);
 t.start();

 compared with the three for SVG’s timer:

 var t = createTimer(0, -1);
 t.addEventListener('SVGTimer', function() { … }, false);
 t.start();
>>>
>>> See my proposal on another thread, which makes this:
>>>
>>> startTimer(0, false, function() { ... });
>>>
>>
>> I really like the idea of a Timer object. It would allow you to  
>> separate creation from starting, allows you to pause and add other  
>> API's to the interface. Can the constructor be used to simplify the  
>> creation:
>>
>>   var t = new Timer(0, false, function() { ...});
>>
>> which would start the timer immediately, as in your example. Or you  
>> could do:
>>
>>   var t = new Timer(function() { ... });
>>   ...
>>   t.startOneShot(1.76);
>
> I don't expect it to be a common use case to create a timer in one  
> place and stop it in another. That being said, you can do this with  
> the API as proposed:
>
> var t = startTimer(0, false, function() { ... });
> t.stop(); // now you have a set up but non-running timer
> ...
> t.restart(); // now it's actually going
>
> I think wanting the timer to start right away is the more common  
> case, so the API is biased in that direction rather than towards  
> initially not running timers.


I think the reason you don't see the pattern of deferred timer  
triggering is because today you just can't do it. I think the use case  
I described (triggering a timer on an animation or media event) will  
be common if and when we have that ability.

In the above example, does the system guarantee that starting a timer  
and immediately stopping it will not ever fire that timer? I can't  
imagine that guarantee being possible, especially for very short (or  
zero) duration timers. If an implementation chooses to queue up timer  
events as soon as they time out (plus the optimization that zero  
duration timers would immediately queue), they would have to dig into  
that queue and rip out any timers that are stopped. And that might not  
even be desirable in many cases. What should happen when a timer times  
out while a JS function is running and you stop it? Should its event  
still run. I'm sure there are many interesting race conditions  
possible here.

It seems like you would avoid these issues if you could have a param  
to startTimer (or a separate createTimer function) that prevented the  
timer from starting in the first place.

-
~Chris
[EMAIL PROTECTED]




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

Re: [webkit-dev] High Resolution Timer API proposal(s)

[Maciej Stachowiak]

On Oct 3, 2008, at 10:36 AM, Peter Kasting wrote:

On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood  
<[EMAIL PROTECTED]> wrote:
I'd say define it as a minimum precision of 1ms, but browser  
manufacturers can define any precision they wish.



OK, but that only pushes the problem space outward rather than  
solving it.  Make CPUs 10x faster and then have one browser with a  
floor of 1 ms and one with 0.1 ms and you have the exact scenario  
we're in today.  Someone writes a tight loop in the 1 ms browser,  
checks that it doesn't use too much CPU, and pushes the build, and  
the 0.1 ms browser gets hosed.


I admit that this one worries me a bit.


My proposed requirement was that 0 timers must be processed as soon as  
possible (on the next return to the event loop) and that besides that  
accuracy to at least 1ms should be provided, but more if possible.


I think 0-delay timers are the most interesting use case and the most  
likely to be set to repeat as an author mistake. A repeating  
indefinite 0-delay timer will quite likely hose any browser supporting  
this API per spec, so it shouldn't be a source of future variance  
problems.


I think the use cases for repeating timers with very small but nonzero  
delays will be pretty rare; I doubt many authors specifically want a  
1ms indefinite repeat for instance. So I think the difference between  
1ms and .1ms will be less likely to be a future issue. If we are  
worried, though, we could require a 1ms floor for repeating or nested  
timers after some number of repeats (some largeish number, like 100)  
if we judge that having a crazy-fast repeating timer indefinitely is  
unlikely to be a valid use.


I recommend sending further feedback to public-webapps.

 - Maciej

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

[webkit-dev] WebCoreLocalizedStrings

[Jason Hullinger]

I'm building a Win32 project that links to WebCore.lib and I'm getting some
linker errors, for instance: Error1error LNK2001: unresolved
external symbol "class WebCore::String __cdecl
WebCore::unknownFileSizeText(void)" ([EMAIL PROTECTED]
@@[EMAIL PROTECTED]@XZ)WebCore.lib

All of them are coming from not finding methods in WebCoreLocalizedStrings.
I see that in WebCoreLocalizedStrings it is calling LPCTSTR_UI_STRING, which
is defined as: #define LPCTSTR_UI_STRING(string, comment)
WebLocalizedLPCTSTRUTF8(&LOCALIZABLE_STRINGS_BUNDLE(FRAMEWORK_NAME), string)

I can not find, for instance, [EMAIL PROTECTED]@@[EMAIL PROTECTED]@XZ,
in the library that WebCore generated, so my question is, do I need to
compile WebCore telling it where to find the localized.strings file, do I
need to compile my project to find the file, or is there something else I'm
missing?

Thanks much,

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

Re: [webkit-dev] New simplified patch review interface for bugs.webkit.org

[Darin Adler]

On Oct 3, 2008, at 2:06 PM, Maciej Stachowiak wrote:

> My suggestion: I think the Edit link should be scrapped or reduced  
> to only the few things you can't do from Review Patch, to reduce  
> confusion.

Related: There are edit links in both bug discussions and the review  
query that would be better if they led to Review Patch instead.

 -- Darin

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

Re: [webkit-dev] New simplified patch review interface for bugs.webkit.org

[Maciej Stachowiak]

On Oct 2, 2008, at 3:13 PM, Adam Roben wrote:

> Hi all-
>  Earlier today I landed a patch to add a new, simplified patch  
> review interface to bugs.webkit.org.

Looks very cool.

My suggestion: I think the Edit link should be scrapped or reduced to  
only the few things you can't do from Review Patch, to reduce confusion.

Regards,
Maciej

>
>
>  For each patch attached to a bugs, there is a new "Review Patch"  
> link:
>
> 
>
>
>  Clicking it will take you to a simple page with the patch on top  
> and a comment form on the bottom:
>
> 
>
>
>  Let me know if you have any problems or ideas for improvement (or  
> file a bug on bugs.webkit.org about it)!
>
> -Adam
> ___
> 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] Proposed Timer API

[Maciej Stachowiak]

On Oct 3, 2008, at 11:15 AM, Geoffrey Garen wrote:

> Hi Chris.
>
>> I really like the idea of a Timer object. It would allow you to
>> separate creation from starting, allows you to pause and add other
>> API's to the interface. Can the constructor be used to simplify the
>> creation:
>>
>>var t = new Timer(0, false, function() { ...});
>>
>> which would start the timer immediately, as in your example.
>
> I think Maciej has made a convincing case that "new Timer" is a bit  
> too coy about the fact that the timer is actually starting.
>
>> Or you could do:
>>
>>var t = new Timer(function() { ... });
>>...
>>t.startOneShot(1.76);
>
> I like your suggestion of adding "startOneShot" (and  
> "startRepeating"?) to the API. I think it would improve clarity over  
> a bool parameter specifying whether the timer repeats.
>
> To create a Timer that isn't scheduled to fire:
>
> new Timer(...)
>
> To create a Timer that is scheduled to fire:
>
> new Timer(...).startOneShot(...)
> new Timer(...).startRepeating(...)

It would be pretty unusual for a method like startOneShot or  
startRepeating to return a value. I'm not sure if you indended that;  
if not

> Or, if we don't like constructors:
>
> createTimer(...).startOneShot(...)
> createTimer(...).startRepeating(...)

We could rename the restart() method to start() (with the same  
semantics, or also taking a bool) and have both createTimer() and  
startTimer() if we think this use case is very important. I don't  
think the need for unstarted timers is very high. However, here's yet  
another tricksy way to achieve the same thing:

var tSpec = [0, false, function() {...});
...
var t = startTimer.apply(window, tSpec);

I think setting up a Timer with the intent of not only starting it but  
defining the timing parameters is extra useless, since then all it  
represents is a function.

Regards,
Maciej


>
>
>> And you could easily add animation or media API's for  
>> synchronization:
>>
>>var t = new Timer(1.76, function() { ... }); // when the timer is
>> triggered, it will run for 1.76 seconds
>>var transition = window.getTransitionForElement(element, "left");
>>transition.trigger(t);
>>...
>>element.style.left = "100px";
>>
>> This would cause the timer to start when the left transition starts
>> and fire its event 1.76 seconds later.
>
> This would be really cool!
>
> Geoff

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

Re: [webkit-dev] Proposed Timer API

[Maciej Stachowiak]

On Oct 3, 2008, at 11:01 AM, Chris Marrin wrote:

>
> On Oct 2, 2008, at 6:13 PM, Maciej Stachowiak wrote:
>>
>> On Oct 2, 2008, at 6:01 PM, Cameron McCormack wrote:
>>
>>> Hi Maciej.
>>>
>>> Cameron McCormack:
> If possible, it would be nice if there could be some degree of
> compatibility between this proposed API and the one in SVG Tiny  
> 1.2:
>
> http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#svg__SVGTimer
>>>
>>> Maciej Stachowiak:
 I considered that, but I don't like the fact that it makes the  
 common
 zero-delay continuation callback case into three lines of code
 instead
 of one, for what I think is no practical benefit.
>>>
>>> Justin’s proposed API seems to need four lines for that case:
>>>
>>> var t = new Timer();
>>> t.repeatCount = 1;
>>> t.addEventListener('timercomplete', function() { … }, false);
>>> t.start();
>>>
>>> compared with the three for SVG’s timer:
>>>
>>> var t = createTimer(0, -1);
>>> t.addEventListener('SVGTimer', function() { … }, false);
>>> t.start();
>>
>> See my proposal on another thread, which makes this:
>>
>> startTimer(0, false, function() { ... });
>>
>
> I really like the idea of a Timer object. It would allow you to  
> separate creation from starting, allows you to pause and add other  
> API's to the interface. Can the constructor be used to simplify the  
> creation:
>
>var t = new Timer(0, false, function() { ...});
>
> which would start the timer immediately, as in your example. Or you  
> could do:
>
>var t = new Timer(function() { ... });
>...
>t.startOneShot(1.76);

I don't expect it to be a common use case to create a timer in one  
place and stop it in another. That being said, you can do this with  
the API as proposed:

var t = startTimer(0, false, function() { ... });
t.stop(); // now you have a set up but non-running timer
...
t.restart(); // now it's actually going

I think wanting the timer to start right away is the more common case,  
so the API is biased in that direction rather than towards initially  
not running timers.

>
> etc.
>
> And you could easily add animation or media API's for synchronization:
>
>var t = new Timer(1.76, function() { ... }); // when the timer is  
> triggered, it will run for 1.76 seconds
>var transition = window.getTransitionForElement(element, "left");
>transition.trigger(t);
>...
>element.style.left = "100px";
>
> This would cause the timer to start when the left transition starts  
> and fire its event 1.76 seconds later.

This doesn't seem very compelling to me. Why not:

element.addEventListener("transitionend", function ()  
{ startTimer(1.76, false, funtion() { ... }, false); } );

Since what a timer is going to do is run script, it doesn't seem like  
a major benefit to avoid running a tiny bit of script to start it.  
Especially if you have to run script to set it up anyway.

  - Maciej


>
>
> -
> ~Chris
> [EMAIL PROTECTED]
>
>
>
>

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

[Maciej Stachowiak]

On Oct 3, 2008, at 10:09 AM, Mike Belshe wrote:

I'm not opposed to any of this; and the new API is definitely  
nicer.  I'll bring up a devil's advocate point.  One thing I hate is  
the Microsoft-style smorgasboard of APIs.  When you want to start a  
timer, you have 6 to choose from, and I hope we can avoid similar  
problems in the DOM.  If keeping the number of APIs is a worthy  
goal, we could just augment the existing API in a backward  
comaptible way:


setTimeout(callback, milliseconds, protect_against_cpu_looping =  
true)


Example to set a 1us timer:

  setTimeout("foo()", 0.001, false)


setInterval could be modified similarly.

There are some downsides; such as difficulty of knowing what  
resolution your browser supports; but maybe that is an advantage as  
well.  You also lose the new features, and OO style.  But, it does  
avoid API-soup.


I did consider this possibility, but it is not backwards compatible.  
Many browsers, including WebKit and Gecko based ones, pass any  
arguments to setTimeout past delay to the timeout function. So  
setTimeout(foo, 0.001, false) would call foo with a first parameter of  
false. Since this construct already has a meaning, I don't think we  
can change it for only the boolean case.


I agree with you that excess of APIs can confuse Web developers.  
Normally our preference is to extend existing facilities. Thus the  
WebKit project's focus on extending existing technologies like HTML  
and CSS, as opposed to investing heavily in total reinventions like  
XForms. Not only are ocean-boiling excercises a waste of time for  
authors, but we as browser engine developers will have to continue to  
support the older technologies forever anyway.


In this case, I think the preponderance of the evidence weighs in  
favor of new API, in part because the existing calls are impossible to  
extend compatibly with extra arguments, and because it is likely  
desirable to feature-test for highres timers, and the extra argument  
approach does not allow for that.


Regards,
Maciej

P.S. I encourage further feedback to be sent to public-webapps for  
those who are willing.




Mike




On Thu, Oct 2, 2008 at 6:07 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:


On Oct 2, 2008, at 5:58 PM, Darin Fisher wrote:

On a separate thread, it was discussed that it is useful to support  
microsecond resolution for future proofness.


I proposed seconds so that it was more clear that fractional  
versions could be used, and because specifying microseconds as  
fractional milliseconds seems awkward to me. But whatever the  
baseline resolution, I think fractional values should be supported  
so there isn't an artificial floor to the resolution on future  
hardware.


 - Maciej



-Darin


On Thu, Oct 2, 2008 at 5:53 PM, Timothy Hatcher  
<[EMAIL PROTECTED]> wrote:

Why double delayInSeconds and not milliseconds to stay consistent?

On Oct 2, 2008, at 5:32 PM, Ojan Vafai wrote:


On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:

> I don't really like the overengineered version. I like the "fairly
> minimalist" version best, but is there anything from the
> overengineered version that should be added to it?

I like the "fairly minimalist" version best as well.

The stop() method does seem a little lonely on the Timer interface  
all

by itself.

If others think any other members from the "overengineered" version
are important I would welcome them to keep stop() company.

+1. My ideal would be the following:

Timer startTimer(double delayInSeconds, bool repeating, Function  
callback);


interface Timer {
void stop();
void resume();
void setDelay(double delayInSeconds);
}

That would cover the majority of cases I've seen in real-world  
javascript code. The argument for setDelay is wanting to be able  
to tweak the delay on the fly (e.g. Google Page Creator has  
autosave code that gets a response from the server  with a longer  
delay time when the server is overloaded).


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


___
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] Database Storage

[David Kilzer]

Not discussed yet is that data is secured between JavaScript from a web page on 
Site A accessing data originally stored from a web page on Site B.  This is not 
allowed.

Note that a web page served from  cannot access a 
database saved from a web page served from , and 
vice-versa.  The protocol (or scheme), hostname, and (implied) port number must 
all match before the database is accessible.

Dave


On Fri, 10/3/08, Brady Eidson <[EMAIL PROTECTED]> wrote:

> To expand on this point,
> 
> The data you store on your user's system should be your
> user's data.   
> It should belong to them, and therefore "security
> concerns" about what  
> they do with it should be moot.
> 
> You can, of course, encrypt the data or otherwise obfuscate
> it before  
> storing it in the database, but that's not enough to
> keep them from  
> poking around messing with it.
> 
> First rule of computer security - all security measures are
> worthless  
> if the attacker gains physical access to the machine.
> 
> ~Brady
> 
> On Oct 3, 2008, at 3:29 AM, Anthony Ricaud wrote:
> 
> > Hi,
> >
> > The database storage (like cookies, localStorage and
> sessionStorage)
> > is stored locally. So everyone can modify it, you
> can't rely on it.
> > It's really easy to do so with the Database panel
> in the Web  
> > Inspector.
> >
> > Anthony.
> >
> > Le 3 oct. 08 à 02:45, Loll a écrit :
> >
> >> Hi,
> >>
> >> Im not sure if this is the right place to ask this
> or not, so im  
> >> sorry
> >> in advance if it is.
> >>
> >> I am interested in the database Storage that is
> now available through
> >> webkit and had a few questions about it.
> >>
> >> My main point of interest is in the security of
> it. Right now, the
> >> website I develop uses PHP and information is
> stored using PHP
> >> sessions. From a servers point of view I can see a
> lot of advantages
> >> of storing such data locally. For one thing , its
> lot less reads and
> >> writes to the server, making it a bit faster I
> would expect.
> >>
> >> But how secure is the data? is it secure enough to
> reliably put such
> >> info on a clients system? Im not talking about
> bank data here, but I
> >> am looking at data that I would not want to be
> altered or viewed in
> >> its raw format all the same.
> >>
> >> Is it safe to assume that no one is going to get
> into it , any more
> >> than its safe to assume that no one is going to
> hijack a PHP Session
> >> to gain access to the same data?
> >>
> >> Anyway I just wondered if was a good idea to think
> about moving in  
> >> the
> >> direction of local storage vs server storage and
> what level of data
> >> should be safely stored that way, vs what
> shouldn't be stored that
> >> way.
> >>
> >> Thanks
> >>
> >> Loll
> >> ___
> >> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Database Storage

[Brady Eidson]

To expand on this point,

The data you store on your user's system should be your user's data.   
It should belong to them, and therefore "security concerns" about what  
they do with it should be moot.

You can, of course, encrypt the data or otherwise obfuscate it before  
storing it in the database, but that's not enough to keep them from  
poking around messing with it.

First rule of computer security - all security measures are worthless  
if the attacker gains physical access to the machine.

~Brady

On Oct 3, 2008, at 3:29 AM, Anthony Ricaud wrote:

> Hi,
>
> The database storage (like cookies, localStorage and sessionStorage)
> is stored locally. So everyone can modify it, you can't rely on it.
> It's really easy to do so with the Database panel in the Web  
> Inspector.
>
> Anthony.
>
> Le 3 oct. 08 à 02:45, Loll a écrit :
>
>> Hi,
>>
>> Im not sure if this is the right place to ask this or not, so im  
>> sorry
>> in advance if it is.
>>
>> I am interested in the database Storage that is now available through
>> webkit and had a few questions about it.
>>
>> My main point of interest is in the security of it. Right now, the
>> website I develop uses PHP and information is stored using PHP
>> sessions. From a servers point of view I can see a lot of advantages
>> of storing such data locally. For one thing , its lot less reads and
>> writes to the server, making it a bit faster I would expect.
>>
>> But how secure is the data? is it secure enough to reliably put such
>> info on a clients system? Im not talking about bank data here, but I
>> am looking at data that I would not want to be altered or viewed in
>> its raw format all the same.
>>
>> Is it safe to assume that no one is going to get into it , any more
>> than its safe to assume that no one is going to hijack a PHP Session
>> to gain access to the same data?
>>
>> Anyway I just wondered if was a good idea to think about moving in  
>> the
>> direction of local storage vs server storage and what level of data
>> should be safely stored that way, vs what shouldn't be stored that
>> way.
>>
>> Thanks
>>
>> Loll
>> ___
>> 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] shiftLeft property compatibility

[David Kilzer]

Hi David,

Please file a bug/enhancement request on .  This is 
how the WebKit project tracks such requests.

Thanks!

Dave


On Fri, 10/3/08, David Ford <[EMAIL PROTECTED]> wrote:

> We at CNS Vital Signs would like to request that the
> shiftLeft property 
> for the keydown and keyup events be implemented in the
> Safari web browser.
> 
> CNS Vital Signs has developed software that presents a
> series of 
> computerized neurocognitive tests that are designed to be
> used as a 
> routine part of a clinical practice, as a research
> instrument, and in 
> schools or workplaces where health and safety are an issue.
>  The CNS 
> Vital Signs test battery offers 54 languages and has been
> utilized as a 
> research tool in over 35 countries world wide.  The tests
> run on a PC 
> and are designed to collect responses from patients and
> calculate 
> performance scores based on the accuracy and timing of the
> response.  
> The original program was a stand-alone application that is
> downloaded 
> and installed on the PC. We have recently released a web
> version of the 
> same program.
> 
> One of the tests originally written makes use of the right
> and left 
> shift keys.  Patients are asked to press the left shift key
> or the right 
> shift key to respond to a presented rule.  Currently, only
> Internet 
> Explorer has implemented the shiftLeft property for the
> keydown and 
> keyup events.  Our pharmacutical customers require the web
> version of 
> our test be identical in nature to the local version, so we
> have had to 
> restrict all web deployments to support Internet Explorer
> only.
> 
> We have programmed the web application to use the right and
> left arrow 
> keys for other browsers but we have had to restrict
> it's use to clinical 
> practice use.
> 
> Thanks for considering our request.
> David J. Ford
> VP Quality Assurance
> CNS Vital Signs, LLC
> https://www.cnsvs.com
> ___
> 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] Proposed Timer API

[Chris Marrin]

On Oct 3, 2008, at 11:15 AM, Geoffrey Garen wrote:
> Hi Chris.
>
>> I really like the idea of a Timer object. It would allow you to
>> separate creation from starting, allows you to pause and add other
>> API's to the interface. Can the constructor be used to simplify the
>> creation:
>>
>>var t = new Timer(0, false, function() { ...});
>>
>> which would start the timer immediately, as in your example.
>
> I think Maciej has made a convincing case that "new Timer" is a bit  
> too coy about the fact that the timer is actually starting.
>
>> Or you could do:
>>
>>var t = new Timer(function() { ... });
>>...
>>t.startOneShot(1.76);
>
> I like your suggestion of adding "startOneShot" (and  
> "startRepeating"?) to the API. I think it would improve clarity over  
> a bool parameter specifying whether the timer repeats.
>
> To create a Timer that isn't scheduled to fire:
>
> new Timer(...)
>
> To create a Timer that is scheduled to fire:
>
> new Timer(...).startOneShot(...)
> new Timer(...).startRepeating(...)
>
> Or, if we don't like constructors:
>
> createTimer(...).startOneShot(...)
> createTimer(...).startRepeating(...)

Yeah, I fully understand the desire to avoid ctors. I hope Maciej can  
add a deferred start capability to his proposed timer...

-
~Chris
[EMAIL PROTECTED]




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

Re: [webkit-dev] High Resolution Timer API proposal(s)

[Chris Marrin]

On Oct 2, 2008, at 5:16 PM, Aaron Boodman wrote:
> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
> wrote:
>> I don't really like the overengineered version. I like the "fairly
>> minimalist" version best, but is there anything from the
>> overengineered version that should be added to it?
>
> I like the "fairly minimalist" version best as well.
>
> The stop() method does seem a little lonely on the Timer interface all
> by itself.
>
> If others think any other members from the "overengineered" version
> are important I would welcome them to keep stop() company.
>

I think it's important to have the ability to create the timer without  
starting it (a fourth boolean param?) and then a start() method.

-
~Chris
[EMAIL PROTECTED]




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

[webkit-dev] Porting webkit to a new graphics library

[twells]

I was looking for a good layout engine to embed in a TV based product.  From
the research I have done there appeared to be 4 main players (Gecko,
Trident, Presto, and WebKit).  It appears that folks who had used other
layout engines were moving to Webkit.  
I am running a linux kernel on a MIPS based processor.  The chipset is
provided by a vendor which has its own drawing libraries.  I am trying to
figure out the best way to map a ported graphics lib interface.  I started
looking at Cairo.  I was not sure if folks would recommend taking the Cairo
API and creating an implementation which wrapped my proprietary drawing API. 
I don't understand why GTK+ still uses Cairo as well and if they are
inseperable.  I thought Cairo was used mainly for the Windows port.

Secondarily,  our front end currently uses Java.  Our java will be compiled
directly to machine code using GCJ.  I would like to use the top level
WebKit API via JNI.  Most of our drawing commands are in C anyway and go
directly to hardware (i.e. they don't have to come back into Java).  We
don't use Swing.

I am hoping there are folks out there who have run into this same issue and
can share experiences.  In an IRC chat at #webkit I was told I could port
the webkit side that does the drawing.  Documenation in this area is sparse. 
I would like to create an adaptation layer for the proprietary draw API so
that the core of webkit can be updated easily.

Thanks for feedback
twells
-- 
View this message in context: 
http://www.nabble.com/Porting-webkit-to-a-new-graphics-library-tp19803222p19803222.html
Sent from the Webkit mailing list archive at Nabble.com.

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

Re: [webkit-dev] Proposed Timer API

[Geoffrey Garen]

Hi Chris.

> I really like the idea of a Timer object. It would allow you to
> separate creation from starting, allows you to pause and add other
> API's to the interface. Can the constructor be used to simplify the
> creation:
>
> var t = new Timer(0, false, function() { ...});
>
> which would start the timer immediately, as in your example.

I think Maciej has made a convincing case that "new Timer" is a bit  
too coy about the fact that the timer is actually starting.

> Or you could do:
>
> var t = new Timer(function() { ... });
> ...
> t.startOneShot(1.76);

I like your suggestion of adding "startOneShot" (and  
"startRepeating"?) to the API. I think it would improve clarity over a  
bool parameter specifying whether the timer repeats.

To create a Timer that isn't scheduled to fire:

new Timer(...)

To create a Timer that is scheduled to fire:

new Timer(...).startOneShot(...)
new Timer(...).startRepeating(...)

Or, if we don't like constructors:

createTimer(...).startOneShot(...)
createTimer(...).startRepeating(...)

> And you could easily add animation or media API's for synchronization:
>
> var t = new Timer(1.76, function() { ... }); // when the timer is
> triggered, it will run for 1.76 seconds
> var transition = window.getTransitionForElement(element, "left");
> transition.trigger(t);
> ...
> element.style.left = "100px";
>
> This would cause the timer to start when the left transition starts
> and fire its event 1.76 seconds later.

This would be really cool!

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

[Geoffrey Garen]

> Again, I'm wondering how many legitimate uses are there for short  
> timeouts in background tabs/windows.

In a background window:
animation
video
audio
work queues for database or other background processing
something interesting the web hasn't invented yet

To give you some context, Safari used to throttle plug-in timers for  
background windows. The result was that users would see randomly  
choppy content.

In a background tab:
audio
work queues for database or other background processing
something interesting the web hasn't invented yet

Also note that protections for background windows and tabs wouldn't  
solve the majority of the problem we've seen in the wild, which is the  
*foreground* window going crazy in a single-tabbed browsing session.

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

Re: [webkit-dev] Proposed Timer API

[Chris Marrin]

On Oct 2, 2008, at 6:13 PM, Maciej Stachowiak wrote:
>
> On Oct 2, 2008, at 6:01 PM, Cameron McCormack wrote:
>
>> Hi Maciej.
>>
>> Cameron McCormack:
 If possible, it would be nice if there could be some degree of
 compatibility between this proposed API and the one in SVG Tiny  
 1.2:

 http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#svg__SVGTimer
>>
>> Maciej Stachowiak:
>>> I considered that, but I don't like the fact that it makes the  
>>> common
>>> zero-delay continuation callback case into three lines of code
>>> instead
>>> of one, for what I think is no practical benefit.
>>
>> Justin’s proposed API seems to need four lines for that case:
>>
>> var t = new Timer();
>> t.repeatCount = 1;
>> t.addEventListener('timercomplete', function() { … }, false);
>> t.start();
>>
>> compared with the three for SVG’s timer:
>>
>> var t = createTimer(0, -1);
>> t.addEventListener('SVGTimer', function() { … }, false);
>> t.start();
>
> See my proposal on another thread, which makes this:
>
> startTimer(0, false, function() { ... });
>

I really like the idea of a Timer object. It would allow you to  
separate creation from starting, allows you to pause and add other  
API's to the interface. Can the constructor be used to simplify the  
creation:

 var t = new Timer(0, false, function() { ...});

which would start the timer immediately, as in your example. Or you  
could do:

 var t = new Timer(function() { ... });
 ...
 t.startOneShot(1.76);

etc.

And you could easily add animation or media API's for synchronization:

 var t = new Timer(1.76, function() { ... }); // when the timer is  
triggered, it will run for 1.76 seconds
 var transition = window.getTransitionForElement(element, "left");
 transition.trigger(t);
 ...
 element.style.left = "100px";

This would cause the timer to start when the left transition starts  
and fire its event 1.76 seconds later.

-
~Chris
[EMAIL PROTECTED]




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

Re: [webkit-dev] shiftLeft property compatibility

[Mark Rowe]

On Oct 3, 2008, at 10:48 AM, David Ford wrote:

> We at CNS Vital Signs would like to request that the shiftLeft  
> property
> for the keydown and keyup events be implemented in the Safari web  
> browser.

Can you please file an enhancement request at ?

- Mark

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

[Rob Burns]

Hi Peter,

On Oct 3, 2008, at 8:36 PM, Peter Kasting wrote:

On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood  
<[EMAIL PROTECTED]> wrote:
I'd say define it as a minimum precision of 1ms, but browser  
manufacturers can define any precision they wish.



OK, but that only pushes the problem space outward rather than  
solving it.  Make CPUs 10x faster and then have one browser with a  
floor of 1 ms and one with 0.1 ms and you have the exact scenario  
we're in today.  Someone writes a tight loop in the 1 ms browser,  
checks that it doesn't use too much CPU, and pushes the build, and  
the 0.1 ms browser gets hosed.


I admit that this one worries me a bit.


I was going to raise the same issue. Again, I'm wondering how many  
legitimate uses are there for short timeouts in background tabs/ 
windows. For example, the calendar app sets a timeout minutes, days or  
hours in the future and those timers could fire in the background.  
However, for timers set for under 1000 milliseconds, aren't these  
simply resorting to polling. By inhibiting timers when pages are in  
the background (especially with new timer APIs), we encourage web  
application authors to find more appropriate events to key off of.  
Polling may be a popular design pattern, but we should be thinking of  
ways to painlessly break that approach, not facilitate it.


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

[webkit-dev] shiftLeft property compatibility

[David Ford]

We at CNS Vital Signs would like to request that the shiftLeft property 
for the keydown and keyup events be implemented in the Safari web browser.

CNS Vital Signs has developed software that presents a series of 
computerized neurocognitive tests that are designed to be used as a 
routine part of a clinical practice, as a research instrument, and in 
schools or workplaces where health and safety are an issue.  The CNS 
Vital Signs test battery offers 54 languages and has been utilized as a 
research tool in over 35 countries world wide.  The tests run on a PC 
and are designed to collect responses from patients and calculate 
performance scores based on the accuracy and timing of the response.  
The original program was a stand-alone application that is downloaded 
and installed on the PC. We have recently released a web version of the 
same program.

One of the tests originally written makes use of the right and left 
shift keys.  Patients are asked to press the left shift key or the right 
shift key to respond to a presented rule.  Currently, only Internet 
Explorer has implemented the shiftLeft property for the keydown and 
keyup events.  Our pharmacutical customers require the web version of 
our test be identical in nature to the local version, so we have had to 
restrict all web deployments to support Internet Explorer only.

We have programmed the web application to use the right and left arrow 
keys for other browsers but we have had to restrict it's use to clinical 
practice use.

Thanks for considering our request.
David J. Ford
VP Quality Assurance
CNS Vital Signs, LLC
https://www.cnsvs.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] setTimeout as browser speed throttle

[Rob Burns]

Hi Peter,

On Oct 3, 2008, at 4:08 PM, Peter Speck wrote:

> On 03/10/2008, at 14:16, Maciej Stachowiak wrote:
>
>>> [...] Other sites update their title on a timer in a way that is
>>> useful for a background tab. For example, GMail updates the unread
>>> count, which is quite useful on a background tab label. [...]
>
> Maybe the new Timer API should be extended with an option for:  should
> this timer be executed when the page is hidden in a background tab.
>

I think that's a great suggestion.

>
> Animation timers would then specify no, thereby reducing amount of  
> cpu/
> battery consumed.
>
> GMail could specify yes: low-overhead update of the unread count in
> background.

Looking forward, HTML5's 'event' element would be a better approach  
than using setTimeout, but obviously setTimeout would be needed for  
legacy support. I think we should be striving for a set of APIs and  
other standards that avoid this misuse of setTimeout for polling. If  
we have well-supported and well-designed standards (such as the  
'event' element, though it isn't really fleshed out yet) I think it  
becomes difficult to come up with examples that would need a  
background timer at all: though I'm all for providing it for edge  
cases. The only examples I can come up with are those web apps  
incorrectly using timers to resort to background polling (like gmail).

> It would make sense to have the default to be false, and to be the
> last parameter.

Sounds good to me.

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

[Peter Kasting]

On Fri, Oct 3, 2008 at 10:25 AM, Justin Haygood <[EMAIL PROTECTED]>wrote:

>  I'd say define it as a minimum precision of 1ms, but browser
> manufacturers can define any precision they wish.
>

OK, but that only pushes the problem space outward rather than solving it.
 Make CPUs 10x faster and then have one browser with a floor of 1 ms and one
with 0.1 ms and you have the exact scenario we're in today.  Someone writes
a tight loop in the 1 ms browser, checks that it doesn't use too much CPU,
and pushes the build, and the 0.1 ms browser gets hosed.

I admit that this one worries me a bit.

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

[Justin Haygood]

I'd say define it as a minimum precision of 1ms, but browser manufacturers
can define any precision they wish.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Belshe
Sent: Friday, October 03, 2008 1:24 PM
To: Maciej Stachowiak
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] High Resolution Timer API proposal(s)

 

Another devil's advocate argument:

Let's fast-forward for a year or two, and the hires timer exists in some
form.  Do we need to offer any protections against CPU spinning?

 

What if one browser (say the dominant market-leading browser at the time)
implements this with timers that have a 15ms granularity?  Consumers of this
API using a 1ms timer still incur a 15ms delay.  App programmers that don't
test on browsers that do offer hi-res timers will spin the CPU.  Since these
browsers by definition are not market leaders, they'll be forced to
re-introduce the clamp on the new API, and we'll be back where we started.
Is there a way to avoid repeating history?

 

Or am I missing something? :-)

 

Mike

 

 

 

 

 

On Thu, Oct 2, 2008 at 8:44 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:


On Oct 2, 2008, at 8:27 PM, Cameron McCormack wrote:

> Maciej Stachowiak:
>> I think I will mention some of these possible variations when
>> proposing the spec. At Hixie's suggestion I will propose it as a
>> standalone spec on <[EMAIL PROTECTED]>, I recommend that those
>> who
>> wish to follow the discussion subscribe to that list.
>
> Hixie mentioned at one point that he'd like to see WindowTimers in a
> separate spec, I think.  Now that there is the event loop stuff in
> HTML 5 I don't know whether that's still his opinion, but if it is,
> will
> you include setInterval()/setTimeout() in this Web Apps spec?  That
> would be useful for SVG in the future.

I think it would be a good idea to include the older existing timer
APIs, yes.

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] High Resolution Timer API proposal(s)

[Peter Speck]

On 03/10/2008, at 19:09, Mike Belshe wrote:

> I'm not opposed to any of this; and the new API is definitely  
> nicer.  I'll bring up a devil's advocate point.  One thing I hate is  
> the Microsoft-style smorgasboard of APIs.  When you want to start a  
> timer, you have 6 to choose from, and I hope we can avoid similar  
> problems in the DOM.  If keeping the number of APIs is a worthy  
> goal, we could just augment the existing API in a backward  
> comaptible way:
>
> setTimeout(callback, milliseconds, protect_against_cpu_looping =  
> true)
>
> Example to set a 1us timer:
>
>   setTimeout("foo()", 0.001, false)


And future extensions would add even more parameters.

The Google Map API uses an object for such extra parameters, e.g.

setTimeout("foo()", 0.001, { throttle:false, runInBackground:true });

This would allow for future extensions without adding new methods/ 
classes; without having to add yet another API method.



- Peter Speck


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

Re: [webkit-dev] High Resolution Timer API proposal(s)

[Mike Belshe]

Another devil's advocate argument:

Let's fast-forward for a year or two, and the hires timer exists in some
form.  Do we need to offer any protections against CPU spinning?

What if one browser (say the dominant market-leading browser at the time)
implements this with timers that have a 15ms granularity?  Consumers of this
API using a 1ms timer still incur a 15ms delay.  App programmers that don't
test on browsers that do offer hi-res timers will spin the CPU.  Since these
browsers by definition are not market leaders, they'll be forced to
re-introduce the clamp on the new API, and we'll be back where we started.
 Is there a way to avoid repeating history?

Or am I missing something? :-)

Mike





On Thu, Oct 2, 2008 at 8:44 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

>
> On Oct 2, 2008, at 8:27 PM, Cameron McCormack wrote:
>
> > Maciej Stachowiak:
> >> I think I will mention some of these possible variations when
> >> proposing the spec. At Hixie's suggestion I will propose it as a
> >> standalone spec on <[EMAIL PROTECTED]>, I recommend that those
> >> who
> >> wish to follow the discussion subscribe to that list.
> >
> > Hixie mentioned at one point that he'd like to see WindowTimers in a
> > separate spec, I think.  Now that there is the event loop stuff in
> > HTML 5 I don't know whether that's still his opinion, but if it is,
> > will
> > you include setInterval()/setTimeout() in this Web Apps spec?  That
> > would be useful for SVG in the future.
>
> I think it would be a good idea to include the older existing timer
> APIs, yes.
>
> 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] High Resolution Timer API proposal(s)

[Mike Belshe]

I'm not opposed to any of this; and the new API is definitely nicer.  I'll
bring up a devil's advocate point.  One thing I hate is the Microsoft-style
smorgasboard of APIs.  When you want to start a timer, you have 6 to choose
from, and I hope we can avoid similar problems in the DOM.  If keeping the
number of APIs is a worthy goal, we could just augment the existing API in a
backward comaptible way:

setTimeout(callback, milliseconds, protect_against_cpu_looping = true)

Example to set a 1us timer:

  setTimeout("foo()", 0.001, false)


setInterval could be modified similarly.

There are some downsides; such as difficulty of knowing what resolution your
browser supports; but maybe that is an advantage as well.  You also lose the
new features, and OO style.  But, it does avoid API-soup.

Mike




On Thu, Oct 2, 2008 at 6:07 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

>
> On Oct 2, 2008, at 5:58 PM, Darin Fisher wrote:
>
> On a separate thread, it was discussed that it is useful to support
> microsecond resolution for future proofness.
>
>
> I proposed seconds so that it was more clear that fractional versions could
> be used, and because specifying microseconds as fractional milliseconds
> seems awkward to me. But whatever the baseline resolution, I think
> fractional values should be supported so there isn't an artificial floor to
> the resolution on future hardware.
>
>  - Maciej
>
>
> -Darin
>
>
> On Thu, Oct 2, 2008 at 5:53 PM, Timothy Hatcher <[EMAIL PROTECTED]>wrote:
>
>> Why double delayInSeconds and not milliseconds to stay consistent?
>>
>> On Oct 2, 2008, at 5:32 PM, Ojan Vafai wrote:
>>
>> On Thu, Oct 2, 2008 at 5:16 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote:
>>
>>> On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>>> > I don't really like the overengineered version. I like the "fairly
>>> > minimalist" version best, but is there anything from the
>>> > overengineered version that should be added to it?
>>>
>>> I like the "fairly minimalist" version best as well.
>>>
>>> The stop() method does seem a little lonely on the Timer interface all
>>> by itself.
>>>
>>> If others think any other members from the "overengineered" version
>>> are important I would welcome them to keep stop() company.
>>>
>>
>> +1. My ideal would be the following:
>>
>> Timer startTimer(double delayInSeconds, bool repeating,
>> Function callback);
>>
>> interface Timer {
>> void stop();
>> void resume();
>> void setDelay(double delayInSeconds);
>> }
>>
>> That would cover the majority of cases I've seen in real-world javascript
>> code. The argument for setDelay is wanting to be able to tweak the delay on
>> the fly (e.g. Google Page Creator has autosave code that gets a response
>> from the server  with a longer delay time when the server is overloaded).
>>
>> 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
>>
>>
> ___
> 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] High Resolution Timer API proposal(s)

[Peter Kasting]

On Thu, Oct 2, 2008 at 10:00 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

> Here it is: <
> http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0009.html
>  >
>

Thanks for writing this up, Maciej, it looks great to me.

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

Re: [webkit-dev] setTimeout as browser speed throttle

[Peter Kasting]

On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:

> Are you planning to test a specific alternate interval?
>

I believe Mike is raising the Chromium clamp to 4 ms.

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

[webkit-dev] Webkit available to plain embedding?

[Konsta Kokkinen]

I've been searching how to use webkit as plain as possible: My program
creates a X window
(I'm using gentoo linux) and commands webkit to render page I'm wanting to
that window,
nothing else. Yes, I'm NOT wanting to use qt or gtk libraries, just plain
rendering. Is
this possible? If not, is it maybe possible to make it possible?

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

Re: [webkit-dev] High Resolution Timer API proposal(s)

[Peter Speck]

On 03/10/2008, at 03:50, Aaron Boodman wrote:

> One other random idea. What about mixing up the param order for
> parallelism with the existing timer APIs:
>
> Timer startTimer(Function callback, double delay, bool repeating);
> [...]
> Which feels more familiar, but at the same timer better. Less new
> things to remember. Also, I think this argues for the unit to continue
> being milliseconds, again, for familiarity.


Agree on both terms.   Fractional milliseconds are awkward when coming  
from a Cocoa programming world, but in the html/JS world the basic  
unit of time is milliseconds: the Date object uses milliseconds,  
whereas Cocoa's NSDate uses seconds.

Having the same parameters as current API but with duration in seconds  
rather than milliseconds will create lots of bugs for web-developers.  
That's would be a definite gotcha.


- Peter Speck


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

Re: [webkit-dev] setTimeout as browser speed throttle

[Peter Speck]

On 03/10/2008, at 14:16, Maciej Stachowiak wrote:

>> [...] Other sites update their title on a timer in a way that is  
>> useful for a background tab. For example, GMail updates the unread  
>> count, which is quite useful on a background tab label. [...]

Maybe the new Timer API should be extended with an option for:  should  
this timer be executed when the page is hidden in a background tab.

Animation timers would then specify no, thereby reducing amount of cpu/ 
battery consumed.

GMail could specify yes: low-overhead update of the unread count in  
background.

It would make sense to have the default to be false, and to be the  
last parameter.

- Peter Speck


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

Re: [webkit-dev] setTimeout as browser speed throttle

[Rob Burns]

HI Maciej,

On Oct 3, 2008, at 3:16 PM, Maciej Stachowiak wrote:



On Oct 3, 2008, at 3:10 AM, Rob Burns wrote:


Hi Darin,

On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote:

On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:


On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:

On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:




(I don't understand your comment about not having to have it on  
all the time.  Surely if a page is asking for a fast setTimeout  
repeatedly, it would be on "all the time.")


My understanding is that timeBeinPeriod(1) is currently on all  
the time in Chrome, even when no short-delay timers are currently  
pending, thus leading to constant greater power consumption. But  
there is no need for it to be on when there are not fast timers  
pending. See WebCore/platform/win/SharedTimerWin.cpp. I think  
that is a technically better approach than switching based on  
power management state. Feedback welcome, though, and perhaps you  
will still come to a different conclusion.


I think that is a good idea too, but it doesn't help when a fast  
setInterval is active.


That is true. With the webkit.org version of SharedTimerWin,  
though, you can at least close the problematic tab when you hear  
your fan spin up and stop suffering any power drain. It may be  
that running slower is a better option.



Yeah, that's the trade off.  Close the offending tab or let it  
run, but more slowly.


Another option, would be to halt timers for all unexposed tabs  
(i.e., tabs in windows that are not the frontmost tab). Are there  
use-cases or sites that would break with such behavior? The reason  
I raise this option is that the loaded page represents important  
state to the user, but when it is buried on a window, it is  
probably not necessary for it to be actively responding to timer  
callbacks. Closing the tab saves battery life, but burying the tab  
behind another tab would be preferable for the user (a mobile user  
that may not be online when that important state represented by the  
page loaded in the tab is sought again).


There are web apps that a user may legitimately want to continue to  
work in the background. One obvious example is a web-based audio  
player, although in that case it would be a plugin or   
element continuing to do work. Still, if you're going to allow  
plugins and media elements to continue, you may as well allow  
timers. Other sites update their title on a timer in a way that is  
useful for a background tab. For example, GMail updates the unread  
count, which is quite useful on a background tab label. Given these  
kinds of examples, I think pausing anything in a background tab  
would not be a good choice; if that kind of functionality were on  
offer it should be a more explicit user gesture.


I agree with that. To me burying a tab is an explicit and often  
deliberate user gesture. It would take novice users little time to  
adjust to the pausing of buried tabs (pausing with respect to all  
processing: plugins, animated images, and javascript for example). If  
audio is playing and it pauses because the tab is buried, the user  
will quickly come to understand that the tab needs to be exposed and  
to switch to a new window to create the new tab. The audio still plays  
in a background window, just not in a background tab. Until tab  
management gets up to speed, that would be a prudent approach anyway.


All in all, I think we shouldn't overreact on the timer issue. Sites  
that consume egregious amounts of computing resources, whether  
through timers or otherwise, are the minority, and so long as they  
suck in all browsers and not just some, users will blame the site  
and it will be pressured to change. So really (in my opinion),  
matching or beating the CPU consumption of other browsers is the  
target, and we shouldn't go crazy with novel ways to restrict timers  
or anything else. Just avoid looking broken on sites that were only  
tested in IE or Firefox.


My experience is that the problem is much more of a problem (but I'm  
mobile a lot). Adding a new highres timer is a good step, but if  
that's already available, then providing setTimeout a 15 fold  
difference in clamps between WebKit and IE (the primary test browser)  
will really exacerbate the problem (perhaps as much as a significant  
percentage loss in battery-charge-life).


As for trying to avoid restricting timers that merely leads to  
restricting javascript in total. The only reason I would ever want to  
turn off javascript is to control poorly authored timers (and similar  
poorly authored plugins and plugin authoring). So I lose all  
javascript support simply to avoid timers, where I would prefer to  
lose the timer capabilities and still have the remaining javascript or  
maintain all javascript and lose timers for buried tabs.


If we assume the new highres API will not be abused the way setTimeout  
is abu

Re: [webkit-dev] setTimeout as browser speed throttle

[Maciej Stachowiak]

On Oct 3, 2008, at 3:10 AM, Rob Burns wrote:


Hi Darin,

On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote:

On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:


On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:

On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:




(I don't understand your comment about not having to have it on  
all the time.  Surely if a page is asking for a fast setTimeout  
repeatedly, it would be on "all the time.")


My understanding is that timeBeinPeriod(1) is currently on all the  
time in Chrome, even when no short-delay timers are currently  
pending, thus leading to constant greater power consumption. But  
there is no need for it to be on when there are not fast timers  
pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that  
is a technically better approach than switching based on power  
management state. Feedback welcome, though, and perhaps you will  
still come to a different conclusion.


I think that is a good idea too, but it doesn't help when a fast  
setInterval is active.


That is true. With the webkit.org version of SharedTimerWin,  
though, you can at least close the problematic tab when you hear  
your fan spin up and stop suffering any power drain. It may be that  
running slower is a better option.



Yeah, that's the trade off.  Close the offending tab or let it run,  
but more slowly.


Another option, would be to halt timers for all unexposed tabs  
(i.e., tabs in windows that are not the frontmost tab). Are there  
use-cases or sites that would break with such behavior? The reason I  
raise this option is that the loaded page represents important state  
to the user, but when it is buried on a window, it is probably not  
necessary for it to be actively responding to timer callbacks.  
Closing the tab saves battery life, but burying the tab behind  
another tab would be preferable for the user (a mobile user that may  
not be online when that important state represented by the page  
loaded in the tab is sought again).


There are web apps that a user may legitimately want to continue to  
work in the background. One obvious example is a web-based audio  
player, although in that case it would be a plugin or  element  
continuing to do work. Still, if you're going to allow plugins and  
media elements to continue, you may as well allow timers. Other sites  
update their title on a timer in a way that is useful for a background  
tab. For example, GMail updates the unread count, which is quite  
useful on a background tab label. Given these kinds of examples, I  
think pausing anything in a background tab would not be a good choice;  
if that kind of functionality were on offer it should be a more  
explicit user gesture.


All in all, I think we shouldn't overreact on the timer issue. Sites  
that consume egregious amounts of computing resources, whether through  
timers or otherwise, are the minority, and so long as they suck in all  
browsers and not just some, users will blame the site and it will be  
pressured to change. So really (in my opinion), matching or beating  
the CPU consumption of other browsers is the target, and we shouldn't  
go crazy with novel ways to restrict timers or anything else. Just  
avoid looking broken on sites that were only tested in IE or Firefox.


Regards,
Maciej

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

[webkit-dev] emitting a click on the page

[Luka Napotnik]

Hello.

I'm interested it there's a way to emit a click signal with the given
X,Y coordinate to the current page being shown. There probably is an
event handler but I don't know where and how to hook my own click
function to it. If there is, can I please get a hint how to do that.

Greets,
Luka

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

Re: [webkit-dev] setTimeout as browser speed throttle

[Rob Burns]

HI Darin,

On Oct 3, 2008, at 1:22 PM, Darin Fisher wrote:


On Fri, Oct 3, 2008 at 3:10 AM, Rob Burns <[EMAIL PROTECTED]> wrote:
Hi Darin,

On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote:

On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:


On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:

On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:




(I don't understand your comment about not having to have it on  
all the time.  Surely if a page is asking for a fast setTimeout  
repeatedly, it would be on "all the time.")


My understanding is that timeBeinPeriod(1) is currently on all the  
time in Chrome, even when no short-delay timers are currently  
pending, thus leading to constant greater power consumption. But  
there is no need for it to be on when there are not fast timers  
pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that  
is a technically better approach than switching based on power  
management state. Feedback welcome, though, and perhaps you will  
still come to a different conclusion.


I think that is a good idea too, but it doesn't help when a fast  
setInterval is active.


That is true. With the webkit.org version of SharedTimerWin,  
though, you can at least close the problematic tab when you hear  
your fan spin up and stop suffering any power drain. It may be that  
running slower is a better option.



Yeah, that's the trade off.  Close the offending tab or let it run,  
but more slowly.


Another option, would be to halt timers for all unexposed tabs  
(i.e., tabs in windows that are not the frontmost tab). Are there  
use-cases or sites that would break with such behavior? The reason I  
raise this option is that the loaded page represents important state  
to the user, but when it is buried on a window, it is probably not  
necessary for it to be actively responding to timer callbacks.  
Closing the tab saves battery life, but burying the tab behind  
another tab would be preferable for the user (a mobile user that may  
not be online when that important state represented by the page  
loaded in the tab is sought again).


Take care,
Rob


It's a good question.  I suspect though that it could break sites.   
Imagine a calendar application that wishes to periodically wake up  
to see if it should put up an alert to notify you of an upcoming  
event.  Such a feature probably requires the ability to run a timer.


Yes, understood. But this example also requires javascript enabled. If  
a user disables javascript this web app will not work either. I'm  
suggesting WebKit could allow more finegrained control by allowing  
javascript enabled, but timers disabled.


Also this example illustrates how an author of such a calendar web app  
may use setTimeout as a polling device rather than using an event- 
based approach where the application simply sets event timers for  
those alerts. By allowing greater control over disabling setTimeout,  
the authoring community will be forced to learn about better  
approaches to authoring such a web app. Obviously this stuff won't  
happen tomorrow, but we have to take a long view of it from time to  
time and think about what we can do to get there.


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

Re: [webkit-dev] setTimeout as browser speed throttle

[Rob Burns]

Hi Peter,

On Oct 3, 2008, at 12:21 PM, Rob Burns wrote:



On Oct 2, 2008, at 6:28 PM, Peter Kasting wrote:

On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns <[EMAIL PROTECTED]> wrote:
As another drastic anecdotal step, I've turned off javascript on
Safari (my main browser) and turn to other browsers when I find a  
site

that requires javascript. If I don't do that, I find my Macbook Air
battery eaten away in under an hour just because I left pages open
that use setTimeout inappropriately.

Safari doesn't have a lower setTimeout() cap than Firefox, so I  
don't think this data point is meaningful.


This wasn't a comparison of the handling of different browsers. I  
was saying that this is a rather drastic measure that users have to  
take in order to avoid errant javascripts from eating away battery  
storage. It might make sense to allow users to disable timers  
separately from disabling javascript in total. In that way it might  
also encourage authors to use timers appropriately when they might  
not be able to count on timers being enabled always (using them  
only when appropriate then).



Since I fear the logic here has been lost let me try to summarize what  
I'm trying to say on this topic.


 • setTimeout gets used in cases where it is not always the best  
solution for authors: i.e., using for polling when a specified event  
would be a better way to provide interactivity
 • setTimeout is probably most often tested on IE with a clamp of  
15ms and any author testing elsewhere does not focus on power  
consumption issues
 • for these cases where it is not being used correctly, a user of  
Chrome (with a 1ms clamp) will experience 15X processor use over a  
user of IE (with 15ms clamp)
 • the 15x processor utilization will result in an accelerated power  
drain on mobile devices running Chrome compared to those running IE
 • most users will not diagnose the issue down to a specific tab or a  
specific page, but may at times identify the browser or the platform  
as the problem


My approach to dealing with this is to leave any number of pages I  
desire open in Safari my main browser and avoid flash and javascript  
entirely there. If a page requires javascript, I fire up Shira or  
Opera or another browser with javascript and flash enabled and make  
sure I quit the application before I go on battery or immediately  
after viewing the page. This gives me immensely more battery life than  
I would otherwise have given my usage patterns (like having a second  
or even a third battery).


Take care,
Rob___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Database Storage

[Anthony Ricaud]

Hi,

The database storage (like cookies, localStorage and sessionStorage)  
is stored locally. So everyone can modify it, you can't rely on it.  
It's really easy to do so with the Database panel in the Web Inspector.

Anthony.

Le 3 oct. 08 à 02:45, Loll a écrit :

> Hi,
>
> Im not sure if this is the right place to ask this or not, so im sorry
> in advance if it is.
>
> I am interested in the database Storage that is now available through
> webkit and had a few questions about it.
>
> My main point of interest is in the security of it. Right now, the
> website I develop uses PHP and information is stored using PHP
> sessions. From a servers point of view I can see a lot of advantages
> of storing such data locally. For one thing , its lot less reads and
> writes to the server, making it a bit faster I would expect.
>
> But how secure is the data? is it secure enough to reliably put such
> info on a clients system? Im not talking about bank data here, but I
> am looking at data that I would not want to be altered or viewed in
> its raw format all the same.
>
> Is it safe to assume that no one is going to get into it , any more
> than its safe to assume that no one is going to hijack a PHP Session
> to gain access to the same data?
>
> Anyway I just wondered if was a good idea to think about moving in the
> direction of local storage vs server storage and what level of data
> should be safely stored that way, vs what shouldn't be stored that  
> way.
>
> Thanks
>
> Loll
> ___
> 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] setTimeout as browser speed throttle

[Darin Fisher]

On Fri, Oct 3, 2008 at 3:10 AM, Rob Burns <[EMAIL PROTECTED]> wrote:

> Hi Darin,
> On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote:
>
> On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
>>
>> On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:
>>
>> On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>>
>>>
>>>  (I don't understand your comment about not having to have it on all the
 time.  Surely if a page is asking for a fast setTimeout repeatedly, it 
 would
 be on "all the time.")

>>>
>>> My understanding is that timeBeinPeriod(1) is currently on all the time
>>> in Chrome, even when no short-delay timers are currently pending, thus
>>> leading to constant greater power consumption. But there is no need for it
>>> to be on when there are not fast timers pending. See
>>> WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically
>>> better approach than switching based on power management state. Feedback
>>> welcome, though, and perhaps you will still come to a different conclusion.
>>
>>
>> I think that is a good idea too, but it doesn't help when a fast
>> setInterval is active.
>>
>>
>> That is true. With the webkit.org version of SharedTimerWin, though, you
>> can at least close the problematic tab when you hear your fan spin up and
>> stop suffering any power drain. It may be that running slower is a better
>> option.
>>
>
>
> Yeah, that's the trade off.  Close the offending tab or let it run, but
> more slowly.
>
>
> Another option, would be to halt timers for all unexposed tabs (i.e., tabs
> in windows that are not the frontmost tab). Are there use-cases or sites
> that would break with such behavior? The reason I raise this option is that
> the loaded page represents important state to the user, but when it is
> buried on a window, it is probably not necessary for it to be actively
> responding to timer callbacks. Closing the tab saves battery life, but
> burying the tab behind another tab would be preferable for the user (a
> mobile user that may not be online when that important state represented by
> the page loaded in the tab is sought again).
>
> Take care,
> Rob
>


It's a good question.  I suspect though that it could break sites.  Imagine
a calendar application that wishes to periodically wake up to see if it
should put up an alert to notify you of an upcoming event.  Such a feature
probably requires the ability to run a timer.

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

Re: [webkit-dev] setTimeout as browser speed throttle

[Rob Burns]

Hi Darin,

On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote:

On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:


On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote:

On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak <[EMAIL PROTECTED]>  
wrote:




(I don't understand your comment about not having to have it on all  
the time.  Surely if a page is asking for a fast setTimeout  
repeatedly, it would be on "all the time.")


My understanding is that timeBeinPeriod(1) is currently on all the  
time in Chrome, even when no short-delay timers are currently  
pending, thus leading to constant greater power consumption. But  
there is no need for it to be on when there are not fast timers  
pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that  
is a technically better approach than switching based on power  
management state. Feedback welcome, though, and perhaps you will  
still come to a different conclusion.


I think that is a good idea too, but it doesn't help when a fast  
setInterval is active.


That is true. With the webkit.org version of SharedTimerWin, though,  
you can at least close the problematic tab when you hear your fan  
spin up and stop suffering any power drain. It may be that running  
slower is a better option.



Yeah, that's the trade off.  Close the offending tab or let it run,  
but more slowly.


Another option, would be to halt timers for all unexposed tabs (i.e.,  
tabs in windows that are not the frontmost tab). Are there use-cases  
or sites that would break with such behavior? The reason I raise this  
option is that the loaded page represents important state to the user,  
but when it is buried on a window, it is probably not necessary for it  
to be actively responding to timer callbacks. Closing the tab saves  
battery life, but burying the tab behind another tab would be  
preferable for the user (a mobile user that may not be online when  
that important state represented by the page loaded in the tab is  
sought again).


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

Re: [webkit-dev] Javascript window.open handling in GTK

[Gustavo Noronha Silva]

On Wed, 2008-10-01 at 15:18 -0700, Weber, Bernd wrote:
> Playing around with the code for a while now I found that, at least in
> the GTK implementation, window.open(), close(), etc is not
> implemented. Can anyone explain to me why this is not implemented?
> Maybe because of security concerns? Wouldn’t it be better to have a
> setting defined that restricts this feature instead of not
> implementing it at all?!

I think mostly because code has not been written or has not been
reviewed/commited yet. I think what you are trying to do will probably
be helped by these:

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

See you,

-- 
Gustavo Noronha Silva <[EMAIL PROTECTED]>
GNOME contributor: http://www.gnome.org/

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

Re: [webkit-dev] setTimeout as browser speed throttle

[Rob Burns]

Hi Peter,

On Oct 2, 2008, at 6:28 PM, Peter Kasting wrote:


On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns <[EMAIL PROTECTED]> wrote:
As another drastic anecdotal step, I've turned off javascript on
Safari (my main browser) and turn to other browsers when I find a site
that requires javascript. If I don't do that, I find my Macbook Air
battery eaten away in under an hour just because I left pages open
that use setTimeout inappropriately.

Safari doesn't have a lower setTimeout() cap than Firefox, so I  
don't think this data point is meaningful.


This wasn't a comparison of the handling of different browsers. I was  
saying that this is a rather drastic measure that users have to take  
in order to avoid errant javascripts from eating away battery storage.  
It might make sense to allow users to disable timers separately from  
disabling javascript in total. In that way it might also encourage  
authors to use timers appropriately when they might not be able to  
count on timers being enabled always (using them only when appropriate  
then).


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