Opened 9 years ago
Closed 6 years ago
#16845 closed defect (patchwelcome)
On a tablet the showing of virtual keyboard causes a "/dojox/mobile/screenSize/phone" topic to be published
Reported by: | daniel.payne | Owned by: | Patrick Ruzand |
---|---|---|---|
Priority: | undecided | Milestone: | 1.13 |
Component: | DojoX Mobile | Version: | 1.8.3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by )
On a tablet the showing of virtual keyboard causes a "/dojox/mobile/screenSize/phone" message to be emitted which causes the app to change layout in screenSizeAware mode
replicate with "http://keldan.org.uk/dojo/test001.html", use a tablet and select a text field
OR
http://download.dojotoolkit.org/release-1.7.1/dojo-release-1.7.1/dojox/mobile/tests/test_screen-size-aware-demo.html in a wide screen window, drag the bottom border up to simulate the keypad opening
this is caused in common.js
dm.detectScreenSize() ... var sz = Math.min(dim.w, dim.h); ...
replacing with Math.max fixes the problem - but i don't know the side effects
Change History (7)
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
Component: | General → DojoX Mobile |
---|---|
Owner: | set to Eric Durocher |
comment:3 Changed 9 years ago by
I agree that the current situation is not satisfactory:
- In practical terms, I share the feeling that responsive widgets such as ScreenSizeAware should not be influenced by the virtual keyboard showing up - it is disturbing for the user to get, say, one column instead of two just because the keyboard is open. (Moreover, I think this holds on Android, but not on iOS.)
- In terms of design, I think dojox/mobile/common should not decide by itself, it should only notify responsible widgets about the new size - the responsible widgets should have their own policy about how to adapt to the new size. For instance, there could be more than two states (phone and tablet) as currently imposed by dojox/mobile/common.
So I think this is worth a rework, but as I said above I think this shouldn't be just a change in the rules currently used by dojox/mobile/common to decide about the iphone vs tablet topics and CSS classes (currently used by ScreenSizeAware and Opener). In particular, using Math.max(dim.w, dim.h) as you suggest doesn't fit well: ScreenSizeAware would create a 2-column layout even for very small width just because the height is large...
For 2.0 I'm sure there will be a big step forward in the area of responsive widgets.
comment:4 Changed 9 years ago by
Description: | modified (diff) |
---|---|
Status: | new → open |
Summary: | On a tablet ths showing of virtual keyboard causes a "/dojox/mobile/screenSize/phone" → On a tablet the showing of virtual keyboard causes a "/dojox/mobile/screenSize/phone" topic to be published |
comment:5 Changed 9 years ago by
Now, waiting for 2.0... here's a suggestion for a workaround using 1.8 or 1.9 - I didn't have time to test it but you may want to give it a try. The point is to give you the control of the choice between the phone and tablet modes. Sketch:
<div data-dojo-type="dojox/mobile/FixedSplitter" data-dojo-props="orientation:'H', screenSizeAware:true, screenSizeAwareClass: 'mypkg/CustomScreenSizeAware'" >
where CustomScreenSizeAware would be your own subclass of ScreenSizeAware with transformUI() overridden as follows:
transformUI: function(/*String*/mode){ // common being the require function arg. corresponding to dojox/mobile/common var dim = common.getScreenSize(); mode = (...your custom criteria for choosing... ) ? "phone" : "tablet"; this.inherited(mode); }
comment:6 Changed 9 years ago by
Owner: | changed from Eric Durocher to Patrick Ruzand |
---|---|
Status: | open → assigned |
comment:7 Changed 6 years ago by
Milestone: | tbd → 1.12 |
---|---|
Resolution: | → patchwelcome |
Status: | assigned → closed |
Given that no one has shown interest in creating a patch in the past 2+ years, I'm closing this as patchwelcome.
#16846 is a duplicate of this ticket.