It looks like this was broken way back in r2661 when we switched from
$wnd.__captureElement to a static field in DOMImplStandard. I'm fixing it
now and testing the code.
Thanks,
John LaBanca
jlaba...@google.com
On Mon, Jan 4, 2010 at 4:39 PM, John LaBanca jlaba...@google.com wrote:
I'll look
Patch sent for review:
http://gwt-code-reviews.appspot.com/128802/show
Thanks for pointing out this bug.
Thanks,
John LaBanca
jlaba...@google.com
On Tue, Jan 5, 2010 at 11:05 AM, John LaBanca jlaba...@google.com wrote:
It looks like this was broken way back in r2661 when we switched from
committed as r7355
Thanks,
John LaBanca
jlaba...@google.com
On Tue, Jan 5, 2010 at 11:54 AM, John LaBanca jlaba...@google.com wrote:
Patch sent for review:
http://gwt-code-reviews.appspot.com/128802/show
Thanks for pointing out this bug.
Thanks,
John LaBanca
jlaba...@google.com
On
Looks like you're right about that.
@jlabanca: Correct me if I'm wrong, but didn't you refactor this stuff a
while back? Mind having a look to make sure I'm not missing something?
On Sun, Jan 3, 2010 at 2:37 PM, Thomas Broyer t.bro...@gmail.com wrote:
Hi googlers,
In DOMImplMozilla's
I'll look into it tomorrow morning.
Thanks,
John LaBanca
jlaba...@google.com
On Mon, Jan 4, 2010 at 2:37 PM, Joel Webber j...@google.com wrote:
Looks like you're right about that.
@jlabanca: Correct me if I'm wrong, but didn't you refactor this stuff a
while back? Mind having a look to make
Hi googlers,
In DOMImplMozilla's initSyntheticMouseUpEvents is a reference to
$wnd.__captureElem, which is never set (or read) anywhere, making the
workaround fail as being no-op in practice.
Shouldn't it be
@com.google.gwt.user.client.impl.DOMImplStandard::captureElem instead?
--
