ond option. Would like to hear your thoughts.
--
Drew DeVault
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
On Thu, Feb 9, 2012 at 10:33 AM, Simon Fraser wrote:
> On Feb 9, 2012, at 7:03 PM, Xianzhu (Drew) Wang 王显著 wrote:
>
> I searched code and found that the repaint rects are only enabled and used
> on Mac. Chromium just paint the gray mask in layoutTestController.display()
> an
n Wed, Feb 8, 2012 at 11:55 PM, Simon Fraser wrote:
> On Feb 9, 2012, at 12:16 AM, Xianzhu (Drew) Wang 王显著 wrote:
>
> > I'm confused with the expected results of some repaint tests, for
> example, fast/repaint/fixed-scroll-simple.html. The expected pixel result
> (platform/m
Hi,
I'm confused with the expected results of some repaint tests, for example,
fast/repaint/fixed-scroll-simple.html. The expected pixel result
(platform/mac/fast/repaint/fixed-scroll-simple-expected.png) is all masked
by dark gray. Does this mean that no part of the page is repainted?
However, th
t, bots can run tests prematurely, emitting false failures. I
> >> observed this during my gardening, and I think you should check which
> >> revisions of WebKit and Chromium bots used while running tests.
> >>
> >> On Tue, Feb 22, 2011 at 20:16, Drew Wilson
Mihai Parparita wrote:
> It looks like Drew checked in baselines with
> http://trac.webkit.org/changeset/79034 (which may be why
> rebaseline-chromium-webkit-tests isn't doing anything, since it
> already has "correct" pixel baselines), but given
> http://trac.webkit.or
Hi,
I just discovered my plugin was leaking memory on Mac Safari today (531
running under XCode) and did some digging. I'm not much of an expert at
NPAPI but to me it looks like a reference count issue related to an
NPP_GetValue() call for a NPPVpluginScriptableNPObject.
The plugin code I'm using
OK, we'll start looking into this and float out an implementation
proposal/design doc once we understand what needs to be done.
Thanks,
-atw
On Wed, Apr 21, 2010 at 5:46 PM, Maciej Stachowiak wrote:
>
> On Apr 21, 2010, at 5:06 PM, Drew Wilson wrote:
>
> Has anyone done any w
Has anyone done any work/investigation towards implementing the context menu
support in HTML5 (the "contextmenu" attribute and elements with
type="contextMenu") as described here:
http://www.w3.org/TR/html5/interactive-elements.html#context-menus ?
I didn't see anything from a quick browse throug
bugs.webkit.org/show_bug.cgi?id=33654 is fixed.
>
> On Mon, Mar 29, 2010 at 5:47 PM, Drew Wilson wrote:
> > I'll also note that a disproportionate number of those bugs are happening
> on
> > the Qt build. This either means that the Qt build is awesome at
> reproducing
I'll also note that a disproportionate number of those bugs are happening on
the Qt build. This either means that the Qt build is awesome at reproducing
this race condition, or that there's some other flakiness on that build that
is exposed with workers.
-atw
On Mon, Mar 29, 2010 at 5:26 PM, Dari
to post a timer if the scheduleDispatchFunctionsFromMainThread
> comes on main thread - this fixes the test and it is a minimal change.
>
> Drew, let me know if you want to dig deeper in CFRunLoopObserver, otherwise
> I could whip up a patch (post a timer from main thread + postTask change
> from Dum
nctionsFromMainThread() to fire an event to make sure we
have something to process, but actually do the processing from within the
observer.
-atw
On Tue, Mar 9, 2010 at 11:55 AM, Alexey Proskuryakov wrote:
>
> On 09.03.2010, at 11:51, Drew Wilson wrote:
>
> That actually is an in
On Tue, Mar 9, 2010 at 11:34 AM, Dmitry Titov wrote:
> On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov wrote:
>
>>
>> On 09.03.2010, at 9:45, Drew Wilson wrote:
>>
>> Yeah, it's a race condition - it seems to all depend on whether the
>>> worker
On Tue, Mar 9, 2010 at 9:45 AM, Drew Wilson wrote:
> Yeah, it's a race condition - it seems to all depend on whether the worker
> resource gets loaded before the postMessage loop starts. Failure rate is
> around 30-50% on my machine.
>
> It looks like events have priorit
it's 50-50. There is some racing condition somewhere perhaps...
>
>
> On Mon, Mar 8, 2010 at 5:29 PM, Drew Wilson wrote:
>
>> Following up with a related note - does anyone have any insight into how
>> the Cocoa event loop dispatches events from different sources? In
>
quot;suspense on modal UI" and "suspense
> on going into BF cache"? Probably there is.
>
> Dmitrty
>
>
> On Mon, Mar 8, 2010 at 1:45 PM, Drew Wilson wrote:
>
>> So the implication is that every single place that uses tasks has to have
>> an associated act
yakov wrote:
>
>>
>> On 08.03.2010, at 11:21, Drew Wilson wrote:
>>
>> So, my question is: does it surprise anyone that tasks posted via
>>> callOnMainThread() are getting executed even though there's a modal dialog
>>> shown? And is there anything I
Hi all,
This weekend I spent some time trying to track down a regression caused by
r55593. In particular:
http://trac.webkit.org/changeset/55593/trunk/WebCore/dom/Document.cpp
This was a change to Document.postTask() to always use callOnMainThread()
(previously, calls to postTask() on the main t
On Fri, Dec 4, 2009 at 2:00 PM, Maciej Stachowiak wrote:
>
> On Dec 4, 2009, at 1:40 PM, Drew Wilson wrote:
>
> Hi all,
>
> There have been various side discussions regarding the stability/viability
> of Workers and SharedWorkers, and I wanted to make sure we understand
Hi all,
There have been various side discussions regarding the stability/viability
of Workers and SharedWorkers, and I wanted to make sure we understand all of
the concerns, since as far as I know there isn't any one person who has been
privy to all of the conversations (or maybe it's just me that
ome up with more. I don't believe that SharedWorkers will solve those
>> scenarios. I doubt that developers inside or outside of Google will move to
>> a totally async programming model.
>>
>> Sorry that this initial mail is also a little scattered. I'll try to s
idden iframe
between windows as was suggested in the other thread would address this use
case sufficiently.
-atw
On Mon, Nov 30, 2009 at 6:11 PM, Drew Wilson wrote:
> I believe that the offline gmail team uses the Gears flavor of shared
> workers and is planning to migrate to the HTML5 vers
I believe that the offline gmail team uses the Gears flavor of shared
workers and is planning to migrate to the HTML5 version once DB access is
supported from within worker context in shipping browsers.
So I guess that Gmail would be a candidate app that has asked for both.
-atw
On Mon, Nov 30,
On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson wrote:
>
> The pushback on SharedWorkers at Google is because Google teams don't want
> to rewrite their apps to work with workers -- SharedScript lets them
> handle some of the cases SharedWorkers would get them, without having to
> rewrite as much co
As an aside (that doesn't necessarily detract from your point) I'd say that
the WebWorker spec is fairly clear in intent: that there will be a single
sharedworker per domain/name within a given UserAgent. You'd have to parse
the idea of a user agent fairly finely (i.e. treat separate Chrome process
Aside from the ref-counter munging, it still seems like there's value in
using PassRefPtr as a signifier that a given API takes ownership of a
pointer.
So I'm not certain (in the case of HTMLNameCollection) that it'd be a better
solution to change it not to take an ordinary pointer - yes, it would
In this case, HTMLCollection() keeps a reference to the object, so you can't
safely pass in just a raw pointer. Since HTMLCollection keeps it around,
you'd have to do the ref anyway.
-atw
On Tue, Oct 27, 2009 at 10:55 AM, Jens Alfke wrote:
> Looking at how refcounting is implemented in WebCore,
Circling back on this - I have a patch together for the V8 side of this
issue (code generation changes and associated infrastructure). I'm just
waiting for someone to R+ it for me:
https://bugs.webkit.org/show_bug.cgi?id=30240 -- if someone can take a look
at this, I can get this in the tree, and w
Ooops, meant to reply to all.
On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson wrote:
>
>
> On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig wrote:
>
>>
>>
>> That is not true, they are also available in nightly builds at
>> http://nightly.webkit.org/.
>>
>
On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig wrote:
>
>
> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
>
> I'm surprised to see these objections coming up now, weeks after the
>> original discussion, and only after my patch has landed in the tree.
>>
>
&g
e you wrote
JSDOMWindowCustom::audio() - do you see its behavior as unacceptable as
well, or do you have some other code to prevent enumeration of window.audio
that I can generalize for use for SharedWorkers too?
-atw
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson wrote:
> So, two weeks ago I sent
So, two weeks ago I sent an email on this thread stating exactly what I was
planning to do, To whit:
>>>
I do think that we ought to be returning undefined instead of null in those
cases, though, just to catch people who are accidentally using isUndefined()
utility functions from common libraries.
OK, I agree as well - skipping is not a good solution here; I don't think
the status quo is perfect, yet probably not imperfect enough to do anything
about :)
I guess there's just a process wrinkle we need to address on the Chromium
side. It's easy to rebaseline a test in Chromium, but less easy to
I wanted to re-open this discussion with some real-world feedback.
In this case, there was a failure in one of the layout tests on the windows
platform, so following the advice below, aroben correctly checked in an
update to the test expectations instead of skipping the tests.
Downstream, this bus
There is this:
https://bugs.webkit.org/show_bug.cgi?id=22878
The issue extends beyond workers - it's anything that supports the
postMessage() API (window objects, MessagePorts).
As was pointed out previously, there have been some design discussions in
this area, but I haven't seen any patches yet
Yeah, I'm thinking A also. OK, sounds like we're on the same page for A
(which is all I really care about). For B it does impact the web app's
ability to do capabilities detection which seems bad, but it's not worth
arguing about hypotheticals I think.
-atw
On Wed, Sep 23, 2009 at 6:10 PM, Maciej
Following up on this, because I missed Maciej's response.
On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak wrote:
>
> Fair enough. But I would be against user-level preferences that add or
> remove entire APIs. Rather, the preference should affect the behavior of the
> API (possibly making it
On Mon, Sep 21, 2009 at 1:22 PM, Maciej Stachowiak wrote:
>
> Slightly better. The only real difference it would make is if someone tests
> using a === comparison to undefined (as opposed to == or just a plain
> boolean test).
>
>
One reason why I'm pursuing this is that a naive google developer
I think shooting for perfect compatibility might be nice, but is probably
not required.
I do think that we ought to be returning undefined instead of null in those
cases, though, just to catch people who are accidentally using isUndefined()
utility functions from common libraries. It would not be h
So awesome - thanks for doing this, Eric.
It says it's blocked because the builders are red - is it just looking for
compile status across all platforms, or does it actually wait for all unit
tests to be green, or just some subsets of the Mac unit tests, or what?
-atw
On Fri, Sep 18, 2009 at 2:47
posting-messages
>>>
>>> http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data
>>>
>>> I've had some brief discussion with Dave Levin and Drew Wilson on
>>> #chromium IRC about this, and have an approach in mind that follo
x objects (now simply "return null") made it substantially
> more complex, that is the only reason the implementation is not currently
> matching the object clone semantic. JSON was never sufficient for the
> purpose of postMessage, and is also relatively trivially breakable.
&g
On Thu, Sep 10, 2009 at 5:29 PM, Oliver Hunt wrote:
>
>
> This is incorrect, from the bindings point of view the type here should be
> "any", which in the JS bindings means ScriptValue. The actual serialisation
> is by definition bindings dependent, be that JSC or ObjC.
>
Certainly, from a WebID
ructured clone" algorithm laid out
>> in the HTML5 spec:
>>
>> http://dev.w3.org/html5/spec/Overview.html#posting-messages
>> http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data
>>
>> I've had some brief discussion with Dave L
verview.html#posting-messages
> http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data
>
> I've had some brief discussion with Dave Levin and Drew Wilson on
> #chromium IRC about this, and have an approach in mind that follows
> and elaborates on their suggesti
I would agree with Yong Li that fewer style rules are better.
However, what Dave is doing is documenting the *existing* style rules, not
adding new ones. As I suspect we aren't going to suddenly relax the style
guidelines for a mature codebase like WebKit, at the very least having the
style rules a
To be more precise, the HTML5 IDL defines the following:
typedef sequence MessagePortArray;
The types above are all MessagePortArray in the spec, not Array. So it seems
like the intent is that they should indeed get mapped to a vanilla JS Array.
I could make these attributes JS-only - that shou
I'm trying to update MessageEvent to match the current HTML5 spec.
Currently, MessageEvent has two references to MessagePort:
readonly attribute *MessagePort messagePort*;
void initMessageEvent(in DOMString typeArg, in boolean canBubbleArg,
in boolean cancelableArg, in DOMString d
I'm seeing a bunch of leaks when running even simple layout tests (i.e.
run-webkit-tests --debug --leaks fast/js/typeof-syntax.html).
This ring any bells for anyone?:
start
main
dumpRenderTree(int, char const**)
runTestingServerLoop()
runTest(std::basic_string, std::allocator
> const&)
-[NSRunLoop
documents? Since we use a shadow document for loading in
Chromium already, do we have to do something special for dedicated workers
so they inherit their parent's app cache?
-atw
On Sat, Aug 8, 2009 at 7:27 PM, Michael Nordman wrote:
> On Fri, Aug 7, 2009 at 11:06 AM, Drew Wilson wrote:
&
Hi all,
I'm about to work on adding network access support to shared workers. To
refresh your memory, shared workers can outlive any specific document object
- they exit when the last referring document exits.
Current dedicated workers just proxy all network operations over to their
associated Doc
009 at 12:45 PM, Michael Nordman wrote:
>
>> > it sounds like we have one vote for "just log them to the console for
>> every connected document"
>>
>> sgtm
>>
>>
>> On Sat, Aug 1, 2009 at 12:39 PM, Drew Wilson wrote:
>> > Yes, Sha
shared workers. The possibility of multiple
> connected pages, which should "handle it"? Seems good for
> logging/debugging purposes to have them show up in the client's
> inspector, but doesn't sound like a good fit for application execution
> purposes.
>
>
> O
Hi all,
Currently, unhandled exceptions are sent from worker context over to the
parent page where they are logged to the console. This works fine for
dedicated workers, but not for shared workers which can have multiple active
windows.
The immediate solution that springs to mind is to broadcast t
to fix. The relevant code
> is all in BytecodeGenerator::BytecodeGenerator(ProgramNode*
> programNode), since this only affects global scope. The change could
> have far-reaching consequences so we'd have to be on the lookout for Web
> compatibility regressions if we change this.
31 AM, Adam Barth wrote:
> You should test the same thing with window.onload. If I recall
> correctly, you'll see similar inoperability.
>
> Adam
>
>
> On Sun, Jul 19, 2009 at 9:29 AM, Drew Wilson wrote:
> > I was writing a new worker unit test and I noticed tha
I was writing a new worker unit test and I noticed that all of our unit
tests set event handlers in worker global context like so:
onmessage = function(event) { ... do something ... };
I note that Firefox also allows setting event handlers like this:
function onmessage(event) { ... do something .
Hi all,
Over the last couple of weeks I've run into some snags with my refactoring
of the Worker code, most of them caused by a lack of understanding of how
the various interface attributes in the IDL files worked. For example, the
innocuous-sounding NoStaticTables attribute really means "If you om
Having used both Chromium's .gyp solution and WebKit's
. solution, I'd like to add a huge +1 to
anyone interested in doing this for their own port. Especially since the
lack of trybots for webkit means that it's prohibitively difficult for
people to actually test their build changes cross-platform
WebKit is clearly broken with frames, as parent.window.Worker
does not even yield the same host object that invoking "window.Worker"
yields from the parent page context (not surprising, since we're looking at
lexicalGlobalObject() when we shouldn't be).
-atw
On Tue, Jul 7, 200
On Tue, Jul 7, 2009 at 5:25 PM, Adam Barth wrote:
>
> I'd have to look at the code a bit more to know whether this is
> correct. Where does |globalObject| come from?
It comes from the JSDOMWindow object where that constructor is exposed. Case
in point:
#if ENABLE(CHANNEL_MESSAGING)
JSValue JS
so I figure I
must be missing something :)
-atw
On Tue, Jun 23, 2009 at 5:14 PM, Adam Barth wrote:
> [+sam]
>
> On Tue, Jun 23, 2009 at 5:11 PM, Drew Wilson wrote:
> > On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak
> wrote:
> >> Also, there might be a subtle b
OK - I've uploaded a patch here if anyone has a chance to look at it - it's
only about 11 changed lines, so it's pretty small.
https://bugs.webkit.org/show_bug.cgi?id=27010
-atw
On Mon, Jul 6, 2009 at 3:00 PM, Darin Adler wrote:
> On Jul 6, 2009, at 2:52 PM, Drew Wilson
ation() in favor of an explicit
CustomToJS attribute? I'm happy to put together a patach for this.
-atw
On Sat, Jul 4, 2009 at 3:02 PM, Maciej Stachowiak wrote:
>
> On Jul 4, 2009, at 11:52 AM, Drew Wilson wrote:
>
>
> 1) I don't ever actually want a raw JSAbstractWor
I don't know how useful the diff would be, but I uploaded one here - it's
not ready for review yet as it has lots of odd debugging flotsam in it:
https://bugs.webkit.org/attachment.cgi?id=32257&action=review
-atw
On Fri, Jul 3, 2009 at 3:23 PM, Sam Weinig wrote:
>
>
>
I'm working on refactoring some code out of WebCore::Worker into a common
base class to be shared between SharedWorker and Worker.
So I've defined a new AbstractWorker.idl and its associated JS bindings.
AbstractWorker is not intended to be instantiable, so I don't have a
constructor generated for
wrote:
> [+sam]
>
> On Tue, Jun 23, 2009 at 5:11 PM, Drew Wilson wrote:
> > On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak
> wrote:
> >> Also, there might be a subtle bug in the above code: what if
> window.Worker
> >> is first accessed from a different fram
Thanks for the help, guys. I'll steer clear of the mysterious .order file
and take a look at my build file additions instead.
Cheers,
-atw
On Sun, Jun 28, 2009 at 4:14 PM, Maciej Stachowiak wrote:
>
> On Jun 28, 2009, at 3:26 PM, Drew Wilson wrote:
>
> I'm addin
I'm adding the initial APIs for SharedWorkers, which require me to add a
couple of .idl files, as well as implementations in WebCore/workers and JS
bindings in bindings/js.
I'm getting a bunch of weird link errors which I haven't figured out:
"__ZN7WebCore23JSSharedWorkerPrototype4selfEPN3JSC9E
On Thu, Jun 25, 2009 at 2:33 PM, Maciej Stachowiak wrote:
>
> On Jun 25, 2009, at 2:27 PM, Drew Wilson wrote:
>
> (resending to a wider audience - apologies to those of you who receive
>> this twice)
>> Hi all,
>>
>> The HTML5 worker spec has ch
(resending to a wider audience - apologies to those of you who receive this
twice)
Hi all,
The HTML5 worker spec has changed significantly from its earlier
incarnations, in that it's no longer externally visible whether a given
worker thread has shut down or not (there are no more close events surf
On Tue, Jun 23, 2009 at 4:53 PM, Maciej Stachowiak wrote:
>
>
> The code above means that Worker.prototype is set at the time the Worker
> constructor itself is created, which is good. In the line you bolded, a fresh
> prototype object is created, and under the covers it will get cached.
> How
ave lots of bugs in
> the bindings where we attach the __proto__ property of new objects to
> the wrong prototype chain. My specific concern is that we should fix
> these bugs. :)
>
> Adam
>
>
> On Tue, Jun 23, 2009 at 3:38 PM, Drew Wilson wrote:
> > BTW, Adam - can y
BTW, Adam - can you elaborate your specific concerns?
On Tue, Jun 23, 2009 at 3:37 PM, Drew Wilson wrote:
> Not sure. There's language in the WebIDL spec around prototype objects of
> interface objects, but I'm not sure how window.Worker.prototype is intended
> to rel
rth wrote:
> 2009/6/23 Drew Wilson :
> > On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth wrote:
> >>
> >> > I am not even sure all of these should have the same behavior,
> >> > however. For instance, as I read the Web Workers spec, the lexical
> global
&
orker constructors are created equal".
-atw
On Tue, Jun 23, 2009 at 2:20 PM, Drew Wilson wrote:
>
>
> On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth wrote:
>
>>
>> > I am not even sure all of these should have the same behavior,
>> > however. For instanc
On Tue, Jun 23, 2009 at 11:49 AM, Adam Barth wrote:
>
> > I am not even sure all of these should have the same behavior,
> > however. For instance, as I read the Web Workers spec, the lexical global
> > object may be correct thing to use for the Worker constructor.
>
> I looked at the spec briefl
I notice that this is a fairly common idiom in the WebKit JS bindings:
1) Storing away a pointer to the JSDOMGlobalObject in the constructor
JSOptionConstructor::JSOptionConstructor(ExecState* exec, JSDOMGlobalObject*
globalObject)
:
DOMObject(JSOptionConstructor::createStructure(exec->lexical
ecific bugs I submit.
Cheers,
-atw
On Fri, Jun 19, 2009 at 11:54 AM, Maciej Stachowiak wrote:
>
> On Jun 19, 2009, at 11:46 AM, Maciej Stachowiak wrote:
>
>
> On Jun 19, 2009, at 11:05 AM, Drew Wilson wrote:
>
> I absolutely understand that there are ways to proactively fi
r Chromium Patch so I
won't worry about it" list, which if true has troubling implications given
that there are an increasing number of Googlers that are making
contributions to WebKit that have nothing to do with Chromium.
-atw
On Fri, Jun 19, 2009 at 10:51 AM, David Levin wrote:
>
I note that this bug fix:
https://bugs.webkit.org/show_bug.cgi?id=23721
...was not on the list below, and has been waiting for some reviewer love
for a couple of weeks now. Is it falling through the cracks somehow?
-atw
On Fri, Jun 19, 2009 at 4:18 AM, Andrei Popescu wrote:
> Hi,
>
> On Fri, J
For SharedWorkers, the fallback is to select a document from the document
set. It's slightly uglier, though, as I'd need to deal with the case where
the user closes the document while we're trying to load via it. Having a
dedicated shadow frame would be much simpler.
-atw
On Wed, Jun 17, 2009 at 7
Following up again on this - now that my cross-thread MessagePort patch is
getting close to landing, I am moving forward on the SharedWorker design
described earlier in this thread.
I think there is still little clarity around the appcache behavior (dimich:
are you bring over your "shadow frame" co
Any insights here? I'd be happy to add some documentation to Mutex if
someone can verify what the intended behavior is...
-atw "sending emails to webkit-dev during WWDC is probably futile, I know
:)"
On Sat, Jun 6, 2009 at 8:57 AM, Drew Wilson wrote:
> I can't seem to fi
I can't seem to find any documentation as to what the expected behavior of
Mutex.lock() is with regard to calling lock() recursively on the same
thread.
Looking at the pthreads implementation, it appears that when we create the
mutex we pass null as the attributes, which gives us the default behavi
Basically, the spec says "the most appropriate app cache should be used"
(which apparently we're free to interpret however we like), and that the
SharedWorker should have the ability to update its current app cache. I
think that the spec is fine.
As for our implementation - I don't know how appcac
2009/6/1 Alexey Proskuryakov
>
> 02.06.2009, в 1:29, Michael Nordman написал(а):
>
> What is the use case for this? It doesn't seem useful to me - to invoke
>>> update explicitly, one
>>> normally needs to have UI anyway, at which point it's much easier to call
>>> update() directly from a
>>> p
ance would
> not be created provided there is an existing instance already running.
> How to reload an existing worker to utilize new resources in an
> updated cache was left as an exercise to the reader.
>
> At least that's my understanding of the current spec.
>
>
> 20
2009/6/1 Alexey Proskuryakov
>
> 01.06.2009, в 22:37, Drew Wilson написал(а):
>
> 1) Since SharedWorkers aren't explicitly tied to a specific Document, it
> doesn't make sense to have them possibly get loaded from an out-of-date
> version of the app cache. If you
#x27;t easily coordinate the shutdown of
the worker with instantiations of new ones.
- Do nothing at all
-atw
2009/6/1 Alexey Proskuryakov
>
> 22.05.2009, в 3:20, Drew Wilson написал(а):
>
>
>- SharedWorkers have explicit access to the ApplicationCache APIs,
>w
The problem I have with defining permissions on top of anything other than
origin, is that every other aspect of HTML security seems to hang on the
venerable same-origin policy.
Allowing an "application" under "foobar.com/trusted" to have different
permissions from an application under "foobar.com/
t;> On Tue, May 26, 2009 at 8:57 PM, Sam Weinig wrote:
>>
>>>
>>>
>>> On Tue, May 26, 2009 at 5:04 PM, Drew Wilson wrote:
>>>
>>>>
>>>>
>>>> On Tue, May 26, 2009 at 4:43 PM, Sam Weinig wrote:
>>>>
>>
To give the list some insight into the discussions we've had with the Chrome
UX folks:
1) We want to associate some set of enhanced permissions with a given origin
(e.g. https://mail.yahoo.com), and we want the user to be presented with a
single "do you want to grant permissions to https://mail.ya
Has John sufficiently addressed people's concerns about this issue? Perhaps
some of the people who previously expressed concerns in the bug could chime
in here saying whether or not they are bought in now.
We'd like to move forward on getting a reviewer on this change, but we're
not certain what t
ntion for the "default" implementation? I'm
expecting there to be two versions of SharedWorkerRepository - the chromium
version, and the version.
-atw
On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak wrote:
>
> On May 26, 2009, at 10:21 AM, Darin Adler wrote:
>
> On
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
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
t a small style comment.
>
> On May 21, 2009, at 4:20 PM, Drew Wilson wrote:
>
> // Static factory method for getting the correct repository
>> implementation for a given browser
>> static public SharedWorkerRepository* getRepository();
>>
>
> Generally WebKit does no
BTW, it looks like the current Worker implementation doesn't notify the
Worker object when timers/network activity are finished, so an unreferenced
Worker thread won't be terminated in that case. When I get done with this
design mess, I'll log a bug with some tests.
-atw
On Thu, May 7, 2009 at 11
1 - 100 of 112 matches
Mail list logo
