Windows Phone 8 support

[Eric Durocher]

Dojo Mobile must support Windows Phone 8 devices. This includes making the necessary tests/fixes in the code, and a new theme.

[dylan]

I've been asked a few times about this. Do we have a plan in place for this? Adding support for touch and gesture events looks like we'll need to work through ​http://msdn.microsoft.com/en-us/library/ie/jj553857%28v=vs.85%29.aspx at a minimum.

[Eric Durocher]

Yes, absolutely, this ticket represents several subtasks, mainly:

1. abstract webkit-specific code into more general CSS3 code (CSS3 property names, different gradient syntaxes, etc)
2. abstract touch support to include the new IE10 pointer event handling
3. new WP8 theme

For now work has started on item 1.

[Eric Durocher]

This patch (big one! in 3 parts) essentially implements task 1: Dojo Mobile does not run any more in "compat" mode on IE10, instead it uses the browser's support for CSS3 properties (transforms, transitions, animations, etc). This includes:

• code refactoring to replace all occurrences of webkitXyz prefixed properties in the code by calls to a new _css3 module that adds the right prefix (webkit, or nothing on IE10).
• other code refactorings, mainly support for rounded corner masks that use -webkitMaskImage on webkit which has not equivalent in IE10 (I used SVG shapes for this).
• refactoring of all themes CSS to include both -webkit- prefixed and non-prefixed versions of CSS3 properties. This is done using LESS: the new common/css3.less file contains the LESS functions that insert both variants, and (almost) all existing -webkit- properties in the CSS have been replaced by these calls. Some CSS files that were not generated by LESS also had -webkit- properties (common/domButtons and common/transitions), so new LESS files have been added for these.
• The css3.less file also has functions to generate the different gradient syntaxes between webkit and IE10.

Note that I used LESS 1.4.0 to generate the CSS, because I needed the percentage function which was not supported in the version of LESS that was previously used. This explains some formatting differences in the resulting CSS that are not directly related to my changes (mainly newlines between multiple classes in selectors, and "black" replaced by "#000000"). Also, the indentation of .css files in common/domButtons and common/transitions has changed because they are now generated.

Of course the CSS are now bigger because they contain webkit and IE10 variants of properties. I compared the built (i.e. all CSS concatenated) versions of iphone.css and android.css, the size increase is roughly from 100k to 130k. I think this is still acceptable, but we could also document how to regenerate the CSS without IE10 support for users who want to optimize the themes for webkit only (or for IE10 only). For this, we could provide webkit-only and IE10-only versions of css3.less.

[Eric Durocher]

Updated scrollable.js with support for keyframes (different methods to manipulate rules on IE).

[bill]

Looks like a good improvement.

Can you put those dojox/mobile/sniff changes into dojo/sniff instead? They apply to desktop too.

Where is this _css3.js module? Seems like you forgot it from the patch?

Also, out of curiousity, what is the less % feature that you are talking about?

[Eric Durocher]

Thanks for the feedback.

Yes there is another ticket (#15827) to merge dojox/mobile/sniff into dojo/sniff, but I will do that other one separately to avoid mixing things up...

dojox/mobile/_css3.js is the first file in part3 of the patch.

The percent function converts e.g. a 0.5 value into "50%", useful to generate different gradient syntaxes: webkit uses 0..1 positions for color stops, whereas IE10 use percent values (maybe clearer to look at css3.less for examples...)

[bill]

I agree that merging dojox/mobile/sniff into dojo/sniff is a separate task. But, about the new has() flags you are adding: "css3" and "svg": They don't belong in dojox/mobile/sniff, or dojo/sniff either, since they are about features, not about sniffing which browser the user is running. Probably, dojo/has.js is the right place.

Actually, I don't understand what the "css3" flag is supposed to mean. Each modern browser has varying levels of support for CSS3 (see ​http://css3test.com/), so how can you have a boolean flag that says that CSS3 is/isn't supported? Also, it's disappointing to see that supposed feature test based on browser version instead of a true feature test.

About _css3.js, it's fragile how you are determining the CSS property names. As time goes on, webkit will start supporting standard names and later desupport the -webkit prefix. This may be on a property by property basis, rather than all at once. So I think it's best to do the tests like kgf did in [30098] to determine each property name, rather than making assumptions based on the browser.

As a side note, all of this name mapping should really be handled in dojo/dom-style, so that instead of doing:

elem.style[css3.name("transform")] = "translate3d(0px,1px,0px)";

you could do:

domStyle.set(elem, "transform", "translate3d(0px,1px,0px)")

I guess that's outside the scope of this patch though.

[Eric Durocher]

Bill I understand your comments. I agree that has("css3") is not a good name, it was just something easy and short for now. What that means really is has("enough-css3-support-for-dojox-mobile"): transitions and animations mainly. I am not sure this should go to dojo/has since I don't think this is something that can be useful to other modules. Has("svg") could go there though (if useful).

About feature testing (both on what is actually supported and prefixes), I agree in principle, I'll look into this. I am not sure though that it is feasible/reasonable to feature-test everything (do we really want code that waits for a transition to be performed or not?).

[bill]

OK, I thought for feature testing it would just be checking if a certain attribute exists ("transition" in node.style or something like that). I certainly agree you don't want a feature test that actually does an animation.

[bill]

PS: ​http://perfectionkills.com/feature-testing-css-properties/ or ​http://modernizr.com/docs/ may be useful for inspiration.

[Eric Durocher]

New version of the patch taking into account Bill's comments:

• dojox/mobile/_css3.js now does feature testing rather than just has("wekbit"). Note that only the 'webkit' prefix is tested as explained in the comment, but this is indeed cleaner and can be extended if necessary.
• dojox/mobile/sniff.js now also tests CSS3 animation support using feature testing, and the has flag is renamed into has("css3-animations").

[cjolif]

_css3 module should probably be moved to dojox/css3 to benefit to dojox/css3/transition as well which should also be upgraded to work on IE10. See #16497.

[Eric Durocher]

First patch: support for IE10 CSS properties (ie. non -webkit- prefixed) - part 1/3 - Eric Durocher (IBM, CCLA)

[Eric Durocher]

First patch: support for IE10 CSS properties (ie. non -webkit- prefixed) - part 2/3 - Eric Durocher (IBM, CCLA)

[Eric Durocher]

First patch: support for IE10 CSS properties (ie. non -webkit- prefixed) - part 3/3 - Eric Durocher (IBM, CCLA)

[Eric Durocher]

New patch:

• resolved conflicts due to recent commits (bidi)
• fixed typo in some CSS (wekbit->webkit)
• code optimizations in _css3.js (thanks bill)

[cjolif]

In [30295]:

refs #16175. Fist step of WP8 support, support for IE10 CSS properties (ie. non -webkit- prefixed). Part 1. Thanks Eric Durocher (IBM, CCLA). !strict.

[cjolif]

In [30296]:

refs #16175. Fist step of WP8 support, support for IE10 CSS properties (ie. non -webkit- prefixed). Part 2. Thanks Eric Durocher (IBM, CCLA).

[cjolif]

In [30297]:

refs #16175. Fist step of WP8 support, support for IE10 CSS properties (ie. non -webkit- prefixed). Part 3. Thanks Eric Durocher (IBM, CCLA).

[cjolif]

In [30298]:

refs #16175. Fist step of WP8 support, support for IE10 CSS properties (ie. non -webkit- prefixed). Part 4. Thanks Eric Durocher (IBM, CCLA).

[cjolif]

In [30300]:

refs #16175. Fist step of WP8 support, support for IE10 CSS properties (ie. non -webkit- prefixed). Part 5. Thanks Eric Durocher (IBM, CCLA).

[cjolif]

In [30301]:

refs #16175. Fist step of WP8 support, support for IE10 CSS properties (ie. non -webkit- prefixed). Part 6. Thanks Eric Durocher (IBM, CCLA).

[cjolif]

In [30302]:

refs #16175. Fist step of WP8 support, support for IE10 CSS properties (ie. non -webkit- prefixed). Part 7. Thanks Eric Durocher (IBM, CCLA).

[cjolif]

In [30303]:

refs #16175. Fist step of WP8 support, support for IE10 CSS properties (ie. non -webkit- prefixed). Part 8. Thanks Eric Durocher (IBM, CCLA).

[cjolif]

In [30304]:

refs #16175. Fist step of WP8 support, support for IE10 CSS properties (ie. non -webkit- prefixed). Part 9. Thanks Eric Durocher (IBM, CCLA).BM

[cjolif]

In [30305]:

refs #16175. Fist step of WP8 support, support for IE10 CSS properties (ie. non -webkit- prefixed). Part 10. Thanks Eric Durocher (IBM, CCLA).BM

[cjolif]

In [30306]:

refs #16175. Fist step of WP8 support, support for IE10 CSS properties (ie. non -webkit- prefixed). Part 11. Thanks Eric Durocher (IBM, CCLA).BM

[cjolif]

In [30307]:

refs #16175. Fist step of WP8 support, support for IE10 CSS properties (ie. non -webkit- prefixed). Part 12. Thanks Eric Durocher (IBM, CCLA).BM

[Eric Durocher]

IE10 support for pageTurningUtils - Eric Durocher (IBM, CCLA)

[Eric Durocher]

Fix for non-CSS3 browsers - Eric Durocher (IBM, CCLA)

[cjolif]

In [30327]:

refs #16175. Fix for non CSS3-enabled browsers. Thanks Eric Durocher (IBM, CCLA)

[Eric Durocher]

Fixed bug in ToolBarButton? on IE < 10 - Eric Durocher (IBM, CCLA)

[cjolif]

In [30346]:

refs #16175. Fixed bug in ToolBarButton? on IE < 10. Thanks Eric Durocher (IBM, CCLA)

[Eric Durocher]

More CSS related changes for IconContainer? + others - Eric Durocher (IBM, CCLA)

[Eric Durocher]

When applying mobile_ie10_IconContainer_misc.patch, the following file must deleted: dojox/mobile/themes/common/IconContainer_keyframes.css

[Eric Durocher]

Uploaded a first patch for IE10 touch support. This has not been tested yet on an actual touch device, so not ready for commit yet, but this is a first opportunity for feedback. The patch contains the following changes:

• Extend the has("touch") test by testing navigator.msMaxTouchPoints as recommended here: ​http://msdn.microsoft.com/en-us/library/ie/hh673557%28v=vs.85%29.aspx#Feature_detection.

• Make sure all touch event listeners in dojox/mobile are added using the dojo/touch module. This was mostly the case already, there were just a few code pieces that used e.g. has("touch")?"touchstart":"mousedown", they have been replaced by touch.press etc. Note that some places used "touchmove" instead of touch.move on purpose, because of the slight differences between touch.move and the native "touchmove", more details below.

• Enhanced dojo/touch.js to support the new MSPointer* events fired by IE10. The basic idea is: if MSPointer events are supported (detected using navigator.msPointerEnabled), then we connect to them (regardless of whether the device is touch-enabled or not), otherwise we do as before, i.e. connect to either mouse or touch, depending on has("touch"). This is consistent with MS's approach to unify mouse and touch events.

• The code in the first if(hasTouch){...} test should not be necessary with MSPointer, since MSPointerOver and MSPointerOut events are fired natively. Also, the synthetic touch.move event is not needed since MSPointerMove events are always fired with a target set to the node that is under the finger/pointer (unless the pointer has been captured). Of course all this has to be confirmed on an actual touch device.

• I added a new touch.moveNative event type. The existing touch.move had the drawback that stopPropagation() does not work because the event is actually listened to on the document. Some dojox/mobile code needs stopPropagation() to work for move events (and target is not used), so touch.moveNative can be used instead in thoses cases. I hope the doc explains the differences clearly enough.

• Finally updated the test_touch.html test case (which fires explicit "touchstart" etc events, must fire MSPointerDown etc. events instead on IE10).

This works for mouse events in IE10 on a Windows 8 desktop virtual machine, where navigator.msPointerEnabled is true (but without touch support -> navigator.msMaxTouchPoints is undefined). MSPointer events are actually fired and correctly handled for mouse events. This should be a good start given MS's claim that mouse and touch events should be handled in a unified way, but of course the next step is to run this on a touch-enabled device (either simulated or an actual phone/tablet), no doubt more problems will arise...

Feedback very welcome!

[bill]

Replying to edurocher:

Uploaded a first patch for IE10 touch support. This has not been tested yet on an actual touch device, so not ready for commit yet, but this is a first opportunity for feedback.

Thanks for working on that, it's definitely an important feature. It looks like your patch was done before my recent touch.js check in though? I can't apply it cleanly.

The patch contains the following changes:

• Extend the has("touch") test by testing navigator.msMaxTouchPoints as recommended here: ​http://msdn.microsoft.com/en-us/library/ie/hh673557%28v=vs.85%29.aspx#Feature_detection.

Actually, I already checked in that change under a different ticket.

• Enhanced dojo/touch.js to support the new MSPointer* events fired by IE10. The basic idea is: if MSPointer events are supported (detected using navigator.msPointerEnabled), then we connect to them (regardless of whether the device is touch-enabled or not), otherwise we do as before, i.e. connect to either mouse or touch, depending on has("touch"). This is consistent with MS's approach to unify mouse and touch events.

Makes sense. When I read about Microsoft's model I was impressed, because it seems like they did it the right way, i.e. they natively solved the problem that dojo.touch is trying to solve. So in other words, I think the modifications to dojo.touch that you are describing make sense.

• The code in the first if(hasTouch){...} test should not be necessary with MSPointer, since MSPointerOver and MSPointerOut events are fired natively. Also, the synthetic touch.move event is not needed since MSPointerMove events are always fired with a target set to the node that is under the finger/pointer (unless the pointer has been captured). Of course all this has to be confirmed on an actual touch device.

Agreed. (Again, compliments to Microsoft.)

• I added a new touch.moveNative event type. The existing touch.move had the drawback that stopPropagation() does not work because the event is actually listened to on the document. Some dojox/mobile code needs stopPropagation() to work for move events (and target is not used), so touch.moveNative can be used instead in thoses cases. I hope the doc explains the differences clearly enough.

Interesting. I didn't expect anyone to be calling stopPropagation() or preventDefault() on touch.move/"touchmove"/"mousemove", but I apparently I was wrong. Given this revelation, maybe we should just fix touch.move to work "right":

If (for webkit environments) we replace

on(win.doc, "touchmove", function(evt){ ... } );

with

win.doc.addEventListener("touchmove", function(evt){
   // all the old code
   ...
   // fire synthetic touchmove event on the correct node
   on.emit(newNode, "dojotouchmove", ...);
}, true);

and then rewrite touch.move as a listener on dojotouchmove, similar to how we listen to dojotouchover etc.?

We should test to make sure that it's not too slow, since it doubles the number of events.

[Eric Durocher]

Replying to bill:

It looks like your patch was done before my recent touch.js check in though? I can't apply it cleanly.

Right... I just uploaded a new version of the patch based on this morning's trunk.

But, I don't think your patch to support both mouse and touch works well unfortunately, I already had reports saying that some dojox/mobile widgets now fire events twice. It seems that the "more than 30ms later" test is not robust enough (you use the current date so it will depend on how long the touch handler takes to execute right? Plus, I am afraid the delay varies a lot among devices...) I will attach a simple test case.

• Extend the has("touch") test[...]

Actually, I already checked in that change under a different ticket.

OK, the new patch does not modify dojo/has any more.

About touch.move/touch.moveNative, yes that might be a solution... I am keeping as is for now, let's sort the problem above first maybe?

[Eric Durocher]

Test case for duplicate clicks, put in dojox/mobile/tests and run on a touch device.

[bill]

I see. Would it be enough to change the limit to (for example) 500ms?

[bill]

OK, that seems to fix it, I updated touch.js.

[cjolif]

In [30425]:

Refs #16175. More IE10 CSS related changes for IconContainer + others. Thanks Eric Durocher (IBM, CCLA). !strict.

[bill]

See also #16438.

[bill]

FYI, I filed #16624 so we can hopefully get this _css3.js functionality rolled into dojo/dom-style.

[cjolif]

In [30497]:

refs #16175. Remove trailing comma.

[bill]

@edurocher - Are you/Christophe going to check in mobile_ie10_touch.patch? Or should I do it? I'd like to get it in so we can do #16438.

[Eric Durocher]

@bill, I could finally test touch events on a WP8 emulator and did some changes, mainly adding msTouchAction: none styles to some widgets to prevent browser scrolling. There are still problems with the mobile Slider widget, I am working on this but I don't expect this will impact dojo/touch.js so we can commit this and I will do another patch for Slider.

[bill]

OK. Oh, I forgot, the only thing is that I'm skeptical moveNative belongs in dojo/touch, since the dojo/touch module is for normalizing behavior across all browsers. I think it makes sense to refactor has touch.move works, so that you can call stopPropogation(), and actually it may be faster than before. I'll attach a modified version of your patch, see if it works for you.

[bill]

rearchitect touch.move so you can call stopPropgation(). but i'm not getting a lot of touch.move events on iPad, not sure why.

[Eric Durocher]

I think you don't see a lot of moves because you fire dojotouchmove only if the hoveredNode has changed. If you move the emit call outside of the test it works better.

I am still verifying that this works when preventDefault() is called.

[bill]

Replying to edurocher:

I think you don't see a lot of moves because you fire dojotouchmove only if the hoveredNode has changed. If you move the emit call outside of the test it works better.

Ah thanks, of course you are right.

I am still verifying that this works when preventDefault() is called.

Well I wasn't expecting preventDefault() to work; I thought you needed stopPropagation() to work (see comment:33). Maybe the synthetic event could have a preventDefault() method that called evt.preventDefault() on the native touchmove event, but I don't know if that would work or not.

[Eric Durocher]

Yes sorry I did mean stopPropagation(), not preventDefault()... ;) Anyway it works with your patch, once corrected as in the comment above. Maybe we could add the preventDefault redirection too, but I do not reproduce any problem without it.

[Eric Durocher]

MSPointer support in dojo/touch + rearchitect touch.move so you can call stopPropgation() (fixed) - bill+ Eric Durocher (IBM, CCLA)

[Eric Durocher]

OK so I attached new versions of the patches:

• mobile_ie10_touch.patch now contains only dojox/mobile changes for IE10 touch support,
• stoppableTouchMove.2.patch contains MSPointer support + bill's new stoppable touch.move implementation + my fixes (emit dojotouchmove even is target did not change, extra comma removed from test).

[bill]

Thanks. But now that I think about it, don't we need preventDefault() to work in order to stop page scrolling while doing DnD etc.?

[Eric Durocher]

It seems that preventing the initial touchstart is usually enough to stop page scrolling, but I would not swear this works on all mobile browsers uniformly, so yes it may be safer to redirect preventDefault.

[Eric Durocher]

MSPointer (unified mouse/touch) support for IE10 - Eric Durocher (IBM, CCLA)

[bill]

In [30545]:

MSPointer support in dojo/touch, for Microsoft Surface devices. Patch from Eric Durocher (IBM, CCLA).

Also rearchitected how the touch.move event is implemented, to scale better when there are many (non-overlapping) nodes with touchmove listeners. This new architecture allows evt.stopPropagation() to work, but not currently evt.preventDefault().

Refs #16175 !strict.

[cjolif]

In [30546]:

refs #16175. MSPointer (unified mouse/touch) support for IE10. Thanks Eric Durocher (IBM, CCLA). !strict.

[bill]

In [30556]:

Get preventDefault() on touch.move events working again, so that the screen doesn't scroll when you are trying to DnD (see test_dnd.html), refs #16175 !strict

[Eric Durocher]

Forgot to regenerate the holodark IconContainer?.css in previous IconContainer? patch - Eric Durocher (IBM, CCLA)

[Eric Durocher]

Fix error when clicking in scrollable views or Switch widgets on IE10 - Eric Durocher (IBM, CCLA)

[cjolif]

In [30615]:

refs #16175. Fix error when clicking in scrollable views or Switch widgets on IE10. Thanks Eric Durocher (IBM, CCLA). !strict.

[Eric Durocher]

Fix item dragging in editable lsits on IE10 - Eric Durocher (IBM, CCLA)

[cjolif]

In [30638]:

refs #16175. Fix item dragging in editable lists on IE10. Thanks Eric Durocher (IBM, CCLA)

[Eric Durocher]

Augment or adapt mobileGallery CSS for IE10 - Eric Durocher (IBM, CCLA)

[Eric Durocher]

Windows Phone detection in dojo/sniff - Eric Durocher (IBM, CCLA)

[sgrebnov]

Windows Phone theme patches for Dojo. Includes patch for DojoX (+ requied images) and patch for Mobile Gallery demo

[Eric Durocher]

Original patch by Sergey Grebnov, minor changes by Eric Durocher (IBM, CCLA)

[cjolif]

Theming committed in [30977]

[cjolif]

In [30978]:

fixes #16175. Adapt mobileGallery for Windows Phone. Thanks Sergey Grebnov (CLA).

[cjolif]

In [30979]:

refs #16175. Relocate files committed at wrong location.

[cjolif]

In [30980]:

refs #16175. More update to the demo.

[Eric Durocher]

Mobile gallery: fix selected state of back button in "Shapes" tab of Buttons view - Eric Durocher (IBM, CCLA)

[cjolif]

In [30982]:

refs #16175. fix selected state of back button in "Shapes" tab of Buttons view. Thanks Eric Durocher (IBM, CCLA)

[cjolif]

In [30995]:

refs #16175. Make sure windows compat theme is not breaking the build.

[cjolif]

In [30997]:

refs #16175. Be consistent and as _compat exclude webkit also exlcude IE10. !strict.

[Adrian Vasiliu]

Viewport size fix to solve unwanted zoom on some WP8 phones (Lumia 920) - Adrian Vasiliu (IBM, CCLA)

[cjolif]

In [31005]:

refs #16175. Viewport size fix to solve unwanted zoom on some WP8 phones (Lumia 920).Thanks Adrian Vasiliu (IBM, CCLA). !strict.

[bill]

In [31083]:

update _Widget-on.html test to run on IE10, refs #16175

[bill]

In [31085]:

update _HasDropDown.html test to run on IE10, refs #16175

[bill]

In [31086]:

better check for whether Microsoft pointer events being used, same test as done in dojo/touch, refs #16175

[bill]

In [31102]:

fix test on IE10 to emit events that dojo/touch is listening for, refs #16175

[bill]

In [31105]:

Underlying event types from dojo/touch may be "MSPointer*" rather than "mouseover", "mousedown", etc. Fixes regression from [30807] where tabs don't get hover effect on IE10 / Win8. Refs #16175, #16823 !strict.

[sgrebnov]

Sergey Grebnov (CLA)

[sgrebnov]

WindowsThemeForDojoXMobileIssueFixes.patch fixes the following

• test_DatePicker.html: DatePicker? is cropped in portrait
• test_EdgeToEdgeList-editable-sv.html: The heading overlap the list when scrolling
• test_GridLayout-2cols.html and others: Clipped on the right
• test_Slider.html: removed background image for vertical slider knob
• Custom SpinWheel?: “separator” slots do not appear at all, or appear as a gray bar
• Date Spinner: the invalid days (such as Feb 30 etc.) show-up ungrayed.
• dijit/Calendar: selected items are not visible
• Heading: Letters such as ‘g’ and ‘y’ are clipped at the bottom.
• ToggleButton?: the delay between switching from 'selected' to 'checked' state

[sgrebnov]

Fixes Windows measurement issues. Sergey Grebnov (CLA)

[Adrian Vasiliu]

Hi Sergey, Thanks again for these patches. Concerning WindowsThemeForDojoXMobileDOHTestFixes.patch: in most tests, when some measurements are different for IE10 than IE9, this is correctly handled by introducing a distinct <value>IE10 variable. With one exception: dojox/mobile/tests/doh/button/ButtonTests.html where the values of BUTTON_WIDTH_IE and BUTTON_HEIGHT_IE have been modified to match IE10 thus now breaking the test (with WindowsPhone theme) on IE9. Just tell whether you fix it or we should fix it on our side.

[sgrebnov]

Hi Adrian, actually I modified existing BUTTON_WIDTH_IE and BUTTON_HEIGHT_IE variables deliberately because they previously had the same value as non-IE default value (BUTTON_HEIGHT, BUTTON_WIDTH), so I thought they could be used to store IE10 specific values, and standard values will work for IE9. Also I tested this case in IE10 in IE9 compatibility mode and the test passed successfully. But if I missed something and it breaks the test on a real IE9, I think it would be faster if you modify the test by yourselves.

BTW. WP theme officially supports IE10 only so I'm not sure we should test it on IE9.

[Adrian Vasiliu]

Okay, I'll do the adjustment, no problem. In my test on the real IE9 it did fail. (Update: in the meantime I realized that for some reason my IE ran in quirks doc mode. In IE9 doc mode it doesn't fail... Sorry. However this is still puzzling me, because in the past we had 100% success on IE9, I guess in IE9 doc mode... and now it still succeeds despite the values that have been modified... Anyway...)

As far as know, the idea is that we only support IE10 officially, but as long as it doesn't cost much to get something work in other browsers, it is welcome.

[sgrebnov]

Thank you, Adrian.

[sgrebnov]

Reduces theme font sizes. Sergey Grebnov (CLA)

[Adrian Vasiliu]

In [31220]:

refs #16175, Various fixes for the Windows theme, including reduction of the theme font sizes; various fixes of DOH tests on IE10. Thanks Sergey Grebnov (CLA).

[Adrian Vasiliu]

About the above commit: it corresponds to the merge of Sergey's last three patches (thanks!), with a few minor formatting changes plus a style rule removed from ScrollablePane.css/less as a quick fix for a regression found at testing.

[Adrian Vasiliu]

In [31233]:

refs #16175. Fix font size for Heading in the Windows theme (makes .css in sync with .less). Thanks Sergey Grebnov (CLA).

[Eric Durocher]

In [31234]:

refs #16175. Added !mblDisableWindowsTheme config flag to disable automatic selection of the new (experimental) Windows theme.

[sgrebnov]

Sergey Grebnov (CLA)

[sgrebnov]

WindowsThemeForDojoXMobileIssueFixesPart2.patch fixes the following

• ToggleButton?: the checked mark still appears initially, and stays for ever while the background correctly switches from white to black and vice-versa when touching the toggle.
• test_Slider.html: the label “20” at the right side of the horiz. slider is partially covered by the slider
• test_Opener-ActionSheet?-async.html: The opener layout is totally broken.
• test_Calendar-lazy-prog.html: The cancel button is too small (text clipped).
• test_Opener-ColorPalette?(-lazy).html: The last line of colors is smaller than others.
• test_Opener_RoundSelectList-async.html: List items overlap the Done button.
• test_Overlay.html: Broken rendering.
• test_ScrollablePane-demo.html: Clipped on the right.
• test_SimpleDialog.html: Radio buttons are not correctly highlighted when selected.
• test_SwapView-demo.html: Clipped on the right.
• test_Switch.html: Bad layout but switches are correct.
• test_ValuePicker-1slot.html: Text is clipped on the right.
• test_Accordion-demo.html: In “Fixed’” mode, the “Dojo” panel is rendered outside of the rounded white border and it’s text content is not visible. If the “Dojo” panel is not the one selected, its title is also below the white border. The content of the “ScrollableView?” panel is not rendered with a left margin of padding and a white vertical line on the left as the other panels. In “Multi” and “Single” mode, the text content of the “Dojo” panel is not visible, and the content of the “ScrollableView?” panel is not rendered with a left margin of padding and a white vertical line on the left as the other panels.

[Adrian Vasiliu]

In [31260]:

refs #16175. Various fixes for Windows theme (in the theme and in tests). Thanks Sergey Grebnov (CLA).

[Adrian Vasiliu]

In [31262]:

refs #16175. Added dep. on dojox/mobile/common (which sets the has-feature "windows-theme", now used by SpinWheelSlot?).

[Adrian Vasiliu]

In [31281]:

refs #16175. Quick fix for broken layout of custom-styled buttons with Windows theme. Thanks Sergey Grebnov (CLA).

[Eric Durocher]

In [31296]:

refs #16175, fix dojox/mobile/ComboBox on IE10/Windows 7 to not use MSGesture, which throws error.

[sgrebnov]

The fix improves the test of MSGesture support for ComboBox? control. Sergey Grebnov (CLA)

[Adrian Vasiliu]

(In the meantime, the patch above has been transferred to #17157).