[webkit-dev] webkit-dev Digest, Vol 71, Issue 8
Gyuyoung Kim
gyuyoung.kim at samsung.com
Sun Apr 10 19:45:39 PDT 2011
> I know Samsung is using the feature but they're not sure if they'll be
> supporting it in the future. Are there are other folks who are actively
> using WML?
We're using WML in WebKit trunk now. Even though, there are some
maintenance difficulties,
I think WML needs to be maintained for some time.
BTW, as far as I know, there are some bugs in WML. So, we have plan to
contribute our patches
soon.
- Gyuyoung Kim
-----Original Message-----
From: webkit-dev-bounces at lists.webkit.org [mailto:webkit-dev-
bounces at lists.webkit.org] On Behalf Of webkit-dev-request at lists.webkit.org
Sent: Friday, April 08, 2011 11:00 PM
To: webkit-dev at lists.webkit.org
Subject: webkit-dev Digest, Vol 71, Issue 8
Send webkit-dev mailing list submissions to
webkit-dev at lists.webkit.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
or, via email, send a message with subject or body 'help' to
webkit-dev-request at lists.webkit.org
You can reach the person managing the list at
webkit-dev-owner at lists.webkit.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of webkit-dev digest..."
Today's Topics:
1. Re: Disallowing modal dialogs during unload events (Darin Fisher)
2. Re: Disallowing modal dialogs during unload events
(Maciej Stachowiak)
3. Re: Disallowing modal dialogs during unload events
(Sreeram Ramachandran)
4. Re: An update on new-run-webkit-tests (Dirk Pranke)
5. Re: Disallowing modal dialogs during unload events (Ojan Vafai)
6. Dropping support for WML? (Ryosuke Niwa)
7. Re: Dropping support for WML? (Ryosuke Niwa)
----------------------------------------------------------------------
Message: 1
Date: Thu, 7 Apr 2011 10:21:45 -0700
From: Darin Fisher <darin at chromium.org>
To: Sreeram Ramachandran <sreeram at google.com>
Cc: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] Disallowing modal dialogs during unload
events
Message-ID: <BANLkTinrZ1WWTb3h5GOpLHn1cg60gvNK_g at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
As you know, I'm a very strong advocate of this change. I think even if
other
ports aren't interested in experimenting with this change at the current
time,
that we should proceed to experiment with it in Chromium. I would very much
like us to have data about how many sites are impacted, so that we can share
that with others.
-Darin
On Wed, Apr 6, 2011 at 4:37 PM, Sreeram Ramachandran
<sreeram at google.com>wrote:
> We'd like to disallow modal dialogs (i.e., those arising from calls to
> alert, confirm, prompt or showModalDialog) during unload events
> (beforeunload, unload and pagehide) [1]. Chromium wants to do this
> [2]. Since this affects web compatibility, I'd like to get agreement
> from the other webkit ports as well.
>
> The benefits are:
> + Fewer annoyances for users who are trying to leave a page.
> + In the case of tab close, allows the browser to hide the tab before
> it has finished running the unload or pagehide event handlers (doesn't
> apply to beforeunload); gives the impression of better performance.
>
> This doesn't affect returning a non-null value from beforeunload; that
> will still cause the browser to show the stay-or-leave dialog. We
> think that is sufficient to satisfy legitimate needs to warn the user
> about data loss, etc.
>
> Outside webkit, this has been discussed on whatwg, but without a
> definite conclusion [3]. Firefox seems to be considering this as well
> [4].
>
> All in favour, say aye!
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=56397
> [2] http://code.google.com/p/chromium/issues/detail?id=68780
> [3]
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-
February/025080.html
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=391834
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-
dev/attachments/20110407/eb066bda/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 07 Apr 2011 10:54:00 -0700
From: Maciej Stachowiak <mjs at apple.com>
To: Sreeram Ramachandran <sreeram at google.com>
Cc: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] Disallowing modal dialogs during unload
events
Message-ID: <A12AEF7C-E8F9-4E24-968F-189ED4F11EDE at apple.com>
Content-Type: text/plain; CHARSET=US-ASCII
Is there data on:
- The user impact of modal dialogs being fired from before unload, unload
or page hide - how often does this happen?
- The Web compatibility impact of removing this functionality (are the
sites that do it using it for seemingly legitimate reasons)?
I can think of two ways to gather the data:
1) Add some form of opt-in tracking to see how often users hit a modal
dialog during an unload event, and sites where this is done, so we could
determine if it causes breakage.
2) Run automated Web crawlers to find this out.
Since we have a potential tradeoff between Web compatibility and usability,
it would be good to get some data so that we can weigh the tradeoff.
Side note: when I see a dialog upon leaving a webpage, it is almost always
the beforeunload dialog. I'm not sure I have ever seen a regular alert,
prompt, confirm, or showModalDialog when leaving the page. This is part of
why I'd like to see data. Would we be solving a real problem with this
change, or just a theoretical one?
Regards,
Maciej
On Apr 6, 2011, at 4:37 PM, Sreeram Ramachandran wrote:
> We'd like to disallow modal dialogs (i.e., those arising from calls to
> alert, confirm, prompt or showModalDialog) during unload events
> (beforeunload, unload and pagehide) [1]. Chromium wants to do this
> [2]. Since this affects web compatibility, I'd like to get agreement
> from the other webkit ports as well.
>
> The benefits are:
> + Fewer annoyances for users who are trying to leave a page.
> + In the case of tab close, allows the browser to hide the tab before
> it has finished running the unload or pagehide event handlers (doesn't
> apply to beforeunload); gives the impression of better performance.
>
> This doesn't affect returning a non-null value from beforeunload; that
> will still cause the browser to show the stay-or-leave dialog. We
> think that is sufficient to satisfy legitimate needs to warn the user
> about data loss, etc.
>
> Outside webkit, this has been discussed on whatwg, but without a
> definite conclusion [3]. Firefox seems to be considering this as well
> [4].
>
> All in favour, say aye!
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=56397
> [2] http://code.google.com/p/chromium/issues/detail?id=68780
> [3] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-
February/025080.html
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=391834
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
------------------------------
Message: 3
Date: Thu, 7 Apr 2011 11:31:00 -0700
From: Sreeram Ramachandran <sreeram at google.com>
To: Maciej Stachowiak <mjs at apple.com>
Cc: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] Disallowing modal dialogs during unload
events
Message-ID: <BANLkTi=_qe4zx_=NoSTJZfnThHNt1YXZBA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Thu, Apr 7, 2011 at 10:54, Maciej Stachowiak <mjs at apple.com> wrote:
> Is there data on:
> - The user impact of modal dialogs being fired from before unload, unload
or page hide - how often does this happen?
> - The Web compatibility impact of removing this functionality (are the
sites that do it using it for seemingly legitimate reasons)?
Sorry, I don't have any data at the moment (actually, I don't even
have any examples).
> I can think of two ways to gather the data:
> 1) Add some form of opt-in tracking to see how often users hit a modal
dialog during an unload event, and sites where this is done, so we could
determine if it causes breakage.
We can collect aggregate stats from Chromium, but our privacy policy
won't let us collect specific URLs or sites. So, even if we found that
a very small percentage of users are affected by this, we won't be
able to tell which sites they were on, or whether the dialogs were
necessary or annoying.
> 2) Run automated Web crawlers to find this out.
I'll try, but static analysis of js is hard/impossible; but perhaps
I'll be able to find at least a couple of examples.
> Since we have a potential tradeoff between Web compatibility and
usability, it would be good to get some data so that we can weigh the
tradeoff.
>
> Side note: when I see a dialog upon leaving ?a webpage, it is almost
always the beforeunload dialog. I'm not sure I have ever seen a regular
alert, prompt, confirm, or showModalDialog when leaving the page. This is
part of why I'd like to see data. Would we be solving a real problem with
this change, or just a theoretical one?
As agreed on #webkit, we'll proceed by enabling this in chromium and
collecting some aggregate stats (for whatever that's worth), relying
on bug reports to find any specific issues that arise.
------------------------------
Message: 4
Date: Thu, 7 Apr 2011 12:55:39 -0700
From: Dirk Pranke <dpranke at chromium.org>
To: Maciej Stachowiak <mjs at apple.com>
Cc: WebKit-Dev <webkit-dev at lists.webkit.org>
Subject: Re: [webkit-dev] An update on new-run-webkit-tests
Message-ID: <BANLkTi=9+WQtF0oNo5FpTft5LrZXhW1HPQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Maciej,
Thanks for clarifying your concerns. I will address them a little
out-of-order, because I think we probably agree on the important
things even if we disagree on the less-important or more theoretical
things.
First, as far as the "future" discoveries go, I agree we should try to
fix as many of the known issues as possible before cutting over. It
may be that many or all of them have already been fixed, as I still
need to verify some of these bugs.
I definitely think the best way forward is to get NRWT bots up and see
how things are working in practice; that way we should have a lot of
data to tell us about the pros and cons of each tool.
That said,
On Thu, Apr 7, 2011 at 4:40 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> If the new test tool causes more failures, or worse yet causes more tests
to give unpredictable results, then that makes our testing system worse.
The main benefit of new-run-webkit-tests, as I understand it, is that it
can run the tests a lot faster. But I don't think it's a good tradeoff to
run the tests a lot faster on the buildbot, if the results we get will be
less reliable. I'm actually kind of shocked that anyone would consider
replacing the test script with one that is known to make our existing tests
less reliable.
>
Ideally, a test harness is stable, consistent, fast, expose as many
bugs as possible, and expose those bugs in a way that is as
reproducible as possible, and we should be shooting for that. But,
just as our code should be bug free but isn't, the test harness may
not be able to be ideal either, at which point, you'll probably
prioritize some aspects of its behavior over others.
For example, ORWT runs the tests in the same order every time in a
single thread, and uses a long timeout. This makes the tests results
very stable and consistent at the cost of potentially hiding some bugs
(tests getting slower but not actually timing out, or tests that
depend on previous tests having run).
NRWT, at least the way we run it by default in Chromium, uses a much
shorter timeout and of course runs things in parallel. This exposes
those bugs, at the cost of making things appear flakier. We have
attempted to build tooling to help with this, because we generally
value finding more bugs over completely stable test runs. For example,
we have an entirely separate tool called the "flakiness dashboard"
that can help track the behavior of tests over time.
So, your "less reliable" might actually be my "finding more bugs" :)
NRWT has at least a couple of hooks that ORWT does not for helping to
tune to your desired preferences, and we can configure them on a
port-by-port basis.
> I don't really care why tests would turn flaky. It's entirely possible
that these are bugs in the tests themselves, or in the code they are
testing. That should still be fixed.
Of course. I'm certainly not suggesting that we shouldn't fix bugs.
But, practically speaking, obviously we are okay with some tests
failing, because we list them in Skipped files today. It may be that
some of those tests would pass under NRWT, and we don't know that,
either (because NRWT re-uses the existing Skipped files as-is. At some
point we might want to change this).
You mentioned that the "main benefit" of NRWT is that it is faster,
but another benefit is that you can classify the expected failures
better using NRWT, and detect real changes in the failure. If a test
that used to render pixels incorrectly now actually has a different
render tree, we'll catch that. If it starts crashing, we'll catch
that. ORWT only has "run and expect it to pass" or "Skip and
potentially miss something changing". I think I actually consider this
more useful than the speed improvements.
>
> Nor do I think that marking tests as flaky in the expectations file means
we are not losing test coverage. If a test can randomly pass or fail, and
we know that and the tool expects it, we are nonetheless not getting the
benefit of learning when the test starts failing.
See above. The data is all there, and it's somewhat a question of what
you want to surface where. We have largely attempted to build tools
that get the best of both worlds. Maybe this is partially a question
of what you would like the main waterfall and consoles to tell you,
and perhaps I do not fully understand how different ports would answer
this question?
-- Dirk
------------------------------
Message: 5
Date: Fri, 8 Apr 2011 18:14:24 +1000
From: Ojan Vafai <ojan at chromium.org>
To: Maciej Stachowiak <mjs at apple.com>
Cc: WebKit Development <webkit-dev at lists.webkit.org>
Subject: Re: [webkit-dev] Disallowing modal dialogs during unload
events
Message-ID: <BANLkTinur6W044j8McwBhDiQgFb=VbmzMg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Fri, Apr 8, 2011 at 3:54 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> Side note: when I see a dialog upon leaving a webpage, it is almost
always
> the beforeunload dialog. I'm not sure I have ever seen a regular alert,
> prompt, confirm, or showModalDialog when leaving the page. This is part of
> why I'd like to see data. Would we be solving a real problem with this
> change, or just a theoretical one?
>
In addition to the theoretical user benefit, I've been such a strong
proponent of this change because it would greatly simplify some of
Chromium's cross-process communication during tab/browser close. So, as long
as it doesn't hurt existing, legitimate sites, I'd still like to see this
happen.
I'm happy with the resolution of trying this out in Chromium and getting
some statistics about how often we hit this in the real world.
Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-
dev/attachments/20110408/f9522b24/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 8 Apr 2011 12:09:36 +0300
From: Ryosuke Niwa <rniwa at webkit.org>
To: WebKit Development <webkit-dev at lists.webkit.org>
Subject: [webkit-dev] Dropping support for WML?
Message-ID: <BANLkTimtr=uEjLaUaE+GPnwmGb1_H_1BSg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Greetings all,
We have been discussing the possibility of dropping WML support in WebKit on
IRC for a while now because
1. None of core ports (Mac, Windows, GTK, Qt, & Chromium) use it by
default
2. Maintenance cost is high
I know Samsung is using the feature but they're not sure if they'll be
supporting it in the future. Are there are other folks who are actively
using WML?
Best regards.
Ryosuke Niwa
Software Engineer
Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-
dev/attachments/20110408/b4ea7260/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 8 Apr 2011 04:12:32 -0700
From: Ryosuke Niwa <rniwa at webkit.org>
To: Dirk Schulze <dirk at dschulze.com>
Cc: WebKit Development <webkit-dev at lists.webkit.org>
Subject: Re: [webkit-dev] Dropping support for WML?
Message-ID: <BANLkTi=KrbO0M=C-OFB8rs=gnJY9JOu9Hw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Fri, Apr 8, 2011 at 3:01 AM, Dirk Schulze <dirk at dschulze.com> wrote:
> If you search in the ChangeLogs, you'll see that we still get bug fixes
and
> build fixes for WML.
>
As far as I checked, much of changes in WML are due to changes in Core DOM
and other parts of WebCore. See
http://trac.webkit.org/log/trunk/Source/WebCore/wml
But it seems it is not the case for WML yet. Also, I am unsure if "None of
> the core ports use it by defautl" is a strong argument here.
>
Do you use WML? I'm simply interested in statistics not arguments for or
against the idea of dropping the feature because we're most likely going to
talk about this at the contributor's meeting.
- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-
dev/attachments/20110408/297f278c/attachment-0001.html>
------------------------------
_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
End of webkit-dev Digest, Vol 71, Issue 8
*****************************************
More information about the webkit-dev
mailing list