Hello All,
I am thinking about creating some custom HTML tags to abstract the
process of creating graphical widgets such as clock and calendar. To
make it work, I would imagine I need some interpreter to transform the
custom tags to HTML/CSS/JS before rendering the page. I heard a lot of
My apologies. Please disregard, this is the wrong list for nominations.
On Mon, Sep 28, 2009 at 5:53 PM, Eric Seidel wrote:
> Xiaomei's up to 12 patches. I'm confident she understands and will
> follow WebKit process. I'd like to nominate here for commit bit.
>
> http://trac.webkit.org/search?
Xiaomei's up to 12 patches. I'm confident she understands and will
follow WebKit process. I'd like to nominate here for commit bit.
http://trac.webkit.org/search?q=Xiaomei
Her patches have been reviewed by Darin Adler, Mitz, Simon and myself.
Always nice to have more RTL-enabled WebKit hackers
28.09.2009, в 17:00, Maciej Stachowiak написал(а):
p.s. I now have two "skipping flakey tests" changes up for review:
https://bugs.webkit.org/show_bug.cgi?id=29322
If Brady and Alexey are ok with disabling this test, then I'm fine
with it. I like Alexey's suggestion to have a separate "flak
On Mon, Sep 28, 2009 at 5:01 PM, Maciej Stachowiak wrote:
>
> On Sep 28, 2009, at 4:47 PM, David Levin wrote:
>
> I don't believe that the test was checked in a flaky state. It was solid
> for a long time and then something happened...
>
>
> What's "the test" in this context? The network / creden
On Sep 28, 2009, at 4:47 PM, David Levin wrote:
I don't believe that the test was checked in a flaky state. It was
solid for a long time and then something happened...
What's "the test" in this context? The network / credentials one?
I'll try to add more logging to this test this evening
On Sep 28, 2009, at 4:40 PM, Eric Seidel wrote:
On Fri, Sep 25, 2009 at 2:42 PM, Maciej Stachowiak
wrote:
I like Dave Levin's idea that the first action should be to
instrument the
tests so we can find out why they intermittently fail. Especially
if the
failure is reproducible on the bot
I don't believe that the test was checked in a flaky state. It was solid for
a long time and then something happened...
I'll try to add more logging to this test this evening (after my turn at
helping chromium stay up to date with WebKit is over).
I'll ping Drew about the other test.
Dave
On Mo
On Fri, Sep 25, 2009 at 2:42 PM, Maciej Stachowiak wrote:
> I like Dave Levin's idea that the first action should be to instrument the
> tests so we can find out why they intermittently fail. Especially if the
> failure is reproducible on the bots but not on developer systems.
I like this idea to
A first pass could just handle anything that can serialize to JSON. I
believe this is more or less what FireFox supports at the moment and gets
you half the way there.
On Mon, Sep 28, 2009 at 1:37 PM, Drew Wilson wrote:
> There is this:
> https://bugs.webkit.org/show_bug.cgi?id=22878
>
> The is
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
On 2009-09-28, at 10:23, Chris Campbell wrote:
Hi Tali,
Regarding event.data, there is a chromium issue filed for this here:
http://crbug.com/21299
Given that this would seem to be an issue at the WebKit level, is
there a bug in WebKit bug about this issue?
- Mark
smime.p7s
Descriptio
Hi Tali,
Regarding event.data, there is a chromium issue filed for this here:
http://crbug.com/21299
And a recent architectural discussion on this mailing list:
https://lists.webkit.org/pipermail/webkit-dev/2009-September/009882.html
I haven't been able to make any progress on it lately due to b
Hi,
There are two issues with workers that seem not compatible with the HTML5 spec.
1. Workers can't open the database ("openDatabase" doesn't work)
2. "event.data" is assumed to be a string and you cannot send a complex object.
I checked it on Safari 4 and Chrome.
Is it going to change? Firefox
The Chrome and Safari teams have chosen not to display approximate
progress bars for user interface design reasons.
You can implement a progress bar for a WebKit-based browser by using
the -estimatedProgress method in WebView.h and the associated
notifications WebViewProgressStartedNotifica
I'm wonderring why Chrome and Safari don't add a progress bar which
indicates the progress of loading a html page.
I took a look at all the ViewMsg and ViewHostMsg in Chrome's src, and didn't
find anything related.
So, is that unimpossible to create such a progress bar?
If it's not so hard, how to
16 matches
Mail list logo
