Add basic support for IE 10

[dankurka]

Originally reported on Google Code with ID 8063

IE 10 currently works rather ok with GWT, but for more advanced stuff own permutation
is required. Also for touch devices it would be nice to have PointerEvent support.
Although it is not exactly a standard yet, pointer events is practically only method
to make some stuff work on WP8/RT touch devices. Widget developers can then use pointer
events in IE10 permutations when they need better IE10 support.

Required tasks
 * own permutation
  * review all remaining ie hacks and see what is still needed
 * MSPointerEvent support

I started the work, patch as attachment for initial comments. Currently only permutation
and basic support for PointerEvents added. 

Still missing at least PointerCancel event and study on which hack could be removed
from DOM implementations. Javadocs are also not updated. 

In case somebody plans to test this stuff I also added a separate patch for my playground
code made into Hello project.

Reported by matti@vaadin.com on 2013-03-08 12:38:53

---

• _Attachment: ie10permutation_and_pointerevents.diff_
• Attachment: playgroundOverHelloProject.diff

[dankurka]

Could you post the patch in Gerrit "for initial comments"?

I also wonder if the MSPointerEvents (and MSGesture events) could be used to emulate
the existing touch and gesture events in GWT, rather than add new events. We could
at least do that (if possible) until the specs are finalized.

Reported by t.broyer on 2013-03-08 14:30:59

• Status changed: Accepted

[dankurka]

I worked against SVN, but I can try to push the stuff to gerrit next week. Will probably
also need to sign the contributor agreement.

Some sort of emulation passed my mind also, but API's are quite different and it would
be quite hard to make perfect emulation. It is probably best to first add wrappers
for native stuff and then later add build simplified API "wrapper" for both APIs that
could cover most commonly needed stuff. E.g. just support single "pointer drags" via
one API that would behind the scenes use mouse/touch/pointer events which ever is available.

Reported by matti@vaadin.com on 2013-03-09 09:50:17

[dankurka]

How does this overlap with MGWT ? Are we saying we should support touch events on GWT
which full back to click events in permutations that do not support touch events. I
believe this is what MGWT does?

I agree one simplified API is best but where you can use a specific API if you wish.
For example in MGWT we use the touch/tap event API. This works equally well on permutations
that do not have native touch/tap events where simple mouse click events are used.

Sorry for being a pain since I need to get an application working on WP8 (hence IE10)
, where our application currently uses MGWT/GWT, and I am trying to understand the
best approach and what needs to be done in GWT and what needs to be done MGWT.

Any pointers would be greatful.

Reported by paul.french@kirona.com on 2013-03-11 10:25:18

[dankurka]

According to https://github.com/toolkitchen/PointerEvents, IE10's implementation differs
from the spec they proposed to the W3C, and the spec might still change before reaches
the Recommendation status.

I'd therefore recommend a conservative approach where we allow pointer events to be
registered with addBitlessDomHandler but we don't otherwise add anything else until
the spec is deemed stable enough (indeed, IE10's implementation won't change, so we'll
have to provide a "compatibility layer" at some point, similar to the above-mentioned
project).

Would it be an acceptable approach that third-party libraries such as Vaadin and MGWT
provide the DomEvent implementation?

Reported by t.broyer on 2013-03-13 18:42:43

[dankurka]

Reported by kurka.daniel on 2013-03-16 19:44:03

[dankurka]

Don't know what are the differences with the current implementation and ms proposal,
but I know that with w3 it will take ages for the proposal to become a standard. And
then we'd still need to wait other browsers to really implements pointer events. If/as
iterations for pointer event "standard" is likely it might be best to prefix constants
and event wrappers with "ms" at this point.

The patch I made uses bitless style. Is there still a reason to use "bitfull" style
for a browser that is introduced in 2012?

It is personally fine for me to add stuff only to Vaadin and it will be open source
there for all who need it. But for I'd find it bit sad for gwt community if n+1 third
party widgets/modules have their own wrappers for pointer events. Same for custom ie10
permutation (needed e.g. for css3 style gradients instead of proprietary filters stuff
with older IEs).

Sorry for not pushing the patch to gerrit yet. I have been bit sick and not it appears
that Vaadin is so bit company these days that connecting my google account to our contributor
agreement will take some time :-)

Reported by matti@vaadin.com on 2013-03-19 09:50:34

[dankurka]

My initial work is now finally in gerrit:
https://gwt-review.googlesource.com/#/c/2421/

Cancel events are also in, but I couldn't test them. I couldn't event test them with
plain JS. Don't know how I could cause those cancel events. The device I used was Microsoft
Surface RT table.

One thing that have risen during development. From MSDN: "Note  The APIs described
in this section are not supported in Windows 7." So it might be helpful in some cases
to have feature detection and a module, like there is for touch events.

Reported by matti@vaadin.com on 2013-04-05 12:06:34

[dankurka]

I went thru com.google.gwt.dom.client.DOMImplIE9 a bit to see what could be removed
from it for IE10. Only selectRemoveOption seems to be eligible and that works with
the try catch as well. I'd let IE10 use the IE9 implementation at this point.

A test page for some methods:
http://v3.tahvonen.fi/ie10domtest.html

Notes:
isOrHasChild: non element nodes still has no contains method -> can't be removed

selectRemoveOption: works as like std -> custom implementation can be removed

clientrect still throws for non attached elements

scroll offset stuff seems to work as before. Someone familiar with RTL stuff should
check if those haxies can be removed

getNumericStyleProperty still returns numbers

Reported by matti@vaadin.com on 2013-05-08 09:55:27

[dankurka]

I just updated deferred binding rules in the patch so that compiler don't warn about
fallback stuff in Window, Focus, Http and the "other" DOM modules. Based on Daniels
code comment in RequestImplIE6To9 I chose std implementation instead, otherwise I just
selected IE9 implementation.

I also built a prototype app using a GWT with the related patch. Found no issues there.
It stresses mostly just cssresource (e.g. feeding different gradient/transition css
rules for id10 than for safari) and MsPointer event stuff. Theme in the proto is broken
in several places, but that is just TouchKit prototypes fault. 
http://v3.tahvonen.fi/dart/

Testing in some larger existing GWT app would be nice to do, but I have personally
only done small GWT apps and Vaadin related stuff. Otherwise I currently have no new
stuff to add to this issue. 

Reported by matti@vaadin.com on 2013-05-17 11:37:11

[dankurka]

In case somebody wants to some stubs for ie10 testing I published sources my bit hacky
ie10 playground app (the dart came):
http://dev.vaadin.com/svn/incubator/dart/

Before getting that up and running you'll need:
 * GWT build with the related patch
 * mvn install from http://dev.vaadin.com/svn/branches/touchkit_experimental/TouchKit/vaadin-touchkit-client/

Reported by matti@vaadin.com on 2013-05-21 13:13:10

[dankurka]

Reported by dankurka@google.com on 2013-09-09 08:41:46

• Blocking: #8308

[dankurka]

I agree with t.broyer. Introducing and exposing non yet standardized and MS prefixed
pointer events via com.google.gwt.dom.client doesn't look like the right approach.

The main problem here is, GWT doesn't have a good layering of APIs where we have the
first level that exposes bare bones and another layer on top of it that provides the
compatibility (which I hope we could fix in upcoming years).

For this specific case, I think we should just have a third-party gwt lib to point
our uses so that they can start using these events immediately.

Reported by goktug@google.com on 2013-09-25 22:40:40

[dankurka]

Maybe I am missing something, but:

Deferring to a third party lib is kind of annoying for events because there is no clean
way to extend GWT's event mechanism. These libs have to extend the corresponding DomImpl
and then replace the original one with the extended one via deferred binding.

As soon as two libs are doing the above for different kind of events, one will break.

As an example imagine the MSPointerEvents are handled by a GWT library from Vaadin
as they have done the work so far. They will introduce a DomImplIE10 for these events.
Now imagine you also want to use MGWT which also replaces DomImpls for supporting transitionEnd
events in various browsers (including IE10). It's very likely that you can not use
both libs together then.

If you want to defer such not yet fully standardized events to third party libs I strongly
recommend adding an extension hook to GWT's event system.

Personally I would add a non-MS prefixed PointerEvent API to GWT based on the current
W3C draft and mark it experimental with a note that the API may change once the W3C
spec is final. This means removing the MS prefix from the event classes in the linked
CL and verifying that the event methods match the current W3C spec. Then GWT can use
deferred binding to correct the current differences between W3C and IE10 implementation.

Reported by jens.nehlmeier on 2013-09-25 23:52:05

[dankurka]

Here is a nice summary of changes:
http://msdn.microsoft.com/en-us/library/ie/dn304886(v=vs.85).aspx

At a quick look differences are not that big, especially on those parts that have been
implemented in my patch. Based on that I'd do as Jens suggested. pointerenter/leave
has most relevant changes (?), but I think I didn't even implement support for them
in my patch and if needed at some point, those changes might be possible to emulate
in IE10 permutation.

Reported by matti.tahvonen on 2013-09-26 06:47:41

[dankurka]

The spec is very new, especially if you took into account how long it takes W3C specs
to get mature and finalized (if they ever). Also looking at vendors, safari is not
even onboard yet, not much progress in Chrome as well. So most of the feedback will
be available later and finalized spec might (or might not) have a lot differences.

On the GWT side, what I mean is to have a common library so that MGWT, Vaadin and others
can share. When the things get stabilized and we have proper emulation in place, we
can pull the lib into the SDK.

In the meantime, I'll take a look what we can improve to make it easier to add new
events externally.

Reported by goktug@google.com on 2013-10-01 22:16:07

[dankurka]

FYI, I started looking into making the event system extendable which doesn't look like
too much change and should make the existing code cleaner.

Reported by goktug@google.com on 2013-10-02 20:50:31

[dankurka]

Sounds like a good improvement. It would be great to have common API for some less used
events as well (like transitionEnd).

What about the IE10 permutation? Or do you plan to make user.agent also somehow extensible?
Without common properties users of these "event system extension libraries" will end
up having issues or lots of permutation.

BTW. The discussion seems to happen in two places now, Kurka posted some comments to
gerrit.

Reported by matti@vaadin.com on 2013-10-03 07:41:03

[dankurka]

@goktug: 

I have created a new issue regarding an extendible event mechanism:

https://code.google.com/p/google-web-toolkit/issues/detail?id=8379

Reported by jens.nehlmeier on 2013-10-03 16:33:38

[dankurka]

@jens: thanks for creating the issue

@matti: Having IE10 permutation is a separate issue. We should still have a permutation
if we have others place to diverge the behavior for IE 10 from IE9.

I created a patch for making user.agent more extensible but will not solve all problems:
Patch: https://gwt-review.googlesource.com/#/c/4500/
Discussion: https://groups.google.com/d/topic/google-web-toolkit-contributors/ogU_FVHdu3M/discussion

Reported by goktug@google.com on 2013-10-03 19:21:07

[dankurka]

@goktug:

Yes, at least I need that ie10 permutation in our projects, but I have a sane method
to add proper pointer event support it don't need to be using the "user.agent" property.
AFAIK the core GWT don't necessary need this if pointer events won't be supported,
unless somebody starts to make optimisations or improvements for IE (read: remove old
"IE6 hacks" from more modern IE's). If I remember correctly, there is only one hack
that I dared to remove in the patch, but there would be several other candidates -
probably also for IE9 and IE8 user agent permutations. Daniel asked (in gerrit) me
to add these as issues:

Typed Arrays: https://code.google.com/p/google-web-toolkit/issues/detail?id=8320
StringBuffer: https://code.google.com/p/google-web-toolkit/issues/detail?id=8380
DOM Parser: https://code.google.com/p/google-web-toolkit/issues/detail?id=8381
Tree hack: https://code.google.com/p/google-web-toolkit/issues/detail?id=8382
FocusImpl: https://code.google.com/p/google-web-toolkit/issues/detail?id=8383
LayoutImpl: https://code.google.com/p/google-web-toolkit/issues/detail?id=8384

I hope there is all.

Also note that if custom events should be implemented as separate libraries and there
is no common "user.agent" property, say for ie10, one might end up having several obsolete
permutations when using multiple libraries that provide ie10 specific implementations.
Of course those could be collapsed with some rules in the module description file of
the project that uses those libraries, but I'd guess that would be too hard task for
average user.

Reported by matti@vaadin.com on 2013-10-04 08:38:47

[dankurka]

Reported by dankurka@google.com on 2013-10-04 10:03:04

• Blocking: #8370

[dankurka]

Reported by dankurka@google.com on 2013-10-04 10:03:25

• Blocking: #8369

[dankurka]

Reported by dankurka@google.com on 2013-10-04 10:03:35

• Blocking: #8368

[dankurka]

Reported by dankurka@google.com on 2013-10-04 10:03:46

• Blocking: #8367

[dankurka]

Reported by dankurka@google.com on 2013-10-04 10:03:56

• Blocking: #8366

[dankurka]

@matti: Yes, it makes sense to have IE 10 permutation.  I will take a quick look at
your patch.

Reported by goktug@google.com on 2013-10-05 05:20:20

[dankurka]

Actually this bug is 'block-on' not 'blocking'

Reported by goktug@google.com on 2013-12-17 02:16:33

• Blocked on: #8308, #8366, #8367, #8368, #8369, #8370

[dankurka]

Reported by goktug@google.com on 2013-12-17 02:17:58

• No longer blocking: #8308

[dankurka]

Reported by goktug@google.com on 2013-12-17 02:18:46

• No longer blocking: #8366

[dankurka]

Reported by goktug@google.com on 2013-12-17 02:19:10

• No longer blocking: #8367

[dankurka]

Reported by goktug@google.com on 2013-12-17 02:19:37

• No longer blocking: #8382

[dankurka]

Reported by goktug@google.com on 2013-12-17 02:22:14

• No longer blocking: #8383

[dankurka]

Reported by goktug@google.com on 2013-12-17 02:22:46

• No longer blocking: #8384

[dankurka]

We already released IE10 support in 2.6 and only remaining open issue is the cleanup
for Tree.gwt.xml which is already tracked separately. No reason to keep this one around.

Reported by goktug@google.com on 2014-10-20 00:11:24

• Status changed: Fixed
• Labels added: Milestone-2_6_1