To clarify:
This message isn't meant to say "if you don't like any of these, speak
up" (although you should feel free to speak up, as always). It's
meant to encourage folks to review the forthcomming patches with the
following standard for the underlying behavior change (i.e., not
"just" as patch
Maciej and I discussed this in IRC. We agree that it's important to
discuss the changes more broadly within the project, but we disagree
about the best format for that discussion.
If you're interested in these sorts of changes, please feel free to
add yourself to the CC list of this bug. Mark an
On Fri, Aug 5, 2011 at 5:16 PM, Maciej Stachowiak wrote:
> For example, Mark said that the following patch changes
> HTMLAnchorElement.getParameter:
>
> https://bugs.webkit.org/attachment.cgi?id=102840&action=review
>
> [...] I don't see any mention of the functions that changed behavior in the
On Aug 5, 2011, at 1:39 PM, Adam Barth wrote:
>
>> My proposal is to revert all the patches that changed behavior without
>> incorporating tests, and we can decide how to proceed from there. If it's
>> hard to even tell which those are, then we should just revert the whole
>> patch set. Then
I don't fully understand what's going on with those APIs. My understanding
prior to this morning is that they were special cased by the code
generator. It's on my list of things to investigate today.
Adam
On Aug 5, 2011 1:48 PM, "Sam Weinig" wrote:
> This list doesn't seem to include the chang
This list doesn't seem to include the changes in behavior to addEventListener
and removeEventListerner (from patches like
http://trac.webkit.org/changeset/92469 http://trac.webkit.org/changeset/92433).
Are those intentionally left out?
-Sam
On Aug 5, 2011, at 12:44 PM, Mark Pilgrim wrote:
>
Hi Maciej,
On Fri, Aug 5, 2011 at 1:16 PM, Maciej Stachowiak wrote:
> I have a hard time reading this wall of text, but it seems to me there were
> at least three things wrong with what happened:
I didn't mean to write a wall of test. I wanted to give Darin
complete answers to his questions be
On Fri, Aug 5, 2011 at 1:06 PM, Darin Adler wrote:
> Mark, Adam, thanks for your replies.
>
> It seems obviously OK to do this for new APIs that have not been around long,
> especially ones that never shipped in a production browser, for the same
> reason that we decided to do this for new funct
Hi Adam,
I have a hard time reading this wall of text, but it seems to me there were at
least three things wrong with what happened:
1) Patches mixing refactoring and behavior changes. This is bad. We should aim
whenever possible to separate behavior changes from refactoring. Reviewers
should
Mark, Adam, thanks for your replies.
It seems obviously OK to do this for new APIs that have not been around long,
especially ones that never shipped in a production browser, for the same reason
that we decided to do this for new functions from this point forward. I have no
quibble with that.
Here is the complete list of intentional behavior changes in patches
I've submitted in the past few months, along with bug URLs to show the
discussion / rationale behind each change:
https://bugs.webkit.org/show_bug.cgi?id=63065
IDBFactory.open()
https://bugs.webkit.org/show_bug.cgi?id=63079
I
On Fri, Aug 5, 2011 at 11:12 AM, Darin Adler wrote:
> I assume that the legacy argument refactoring you are doing right now has a
> goal of no behavior changes. But I’ve noticed some cases where arguments are
> not marked optional in a few of the patches. Possibly I misunderstood the
> patch.
Hi Mark.
I assume that the legacy argument refactoring you are doing right now has a
goal of no behavior changes. But I’ve noticed some cases where arguments are
not marked optional in a few of the patches. Possibly I misunderstood the
patch. One example was arguments in canvas rendering contex
13 matches
Mail list logo
