Opened 7 years ago

Closed 4 years ago

#16672 closed defect (patchwelcome)

dojox/mobile/SearchBox: close button deficiencies

Reported by: Adrian Vasiliu Owned by: Damien Mandrioli
Priority: undecided Milestone: tbd
Component: DojoX Mobile Version: 1.8.3
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by Patrick Ruzand)

The following are deficiencies on various browsers of the "close button" (button with a cross icon for clearing the text of the input field) of dojox/mobile/SearchBox:

How to reproduce:

Load http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/mobile/tests/test_FormControls.html (or any app containing a dojox/mobile/SearchBox), then:

a) iPhone 5 iOS 6.0.2 1. Touch the SearchBox => The virtual keyboard shows-up, and the close button too. So far so good. 2. Type some characters, then touch the close button. => KO: pressing the close button has no effect. 3. Touch "Done" to close the virtual keyboard. => KO: the close button still shows-up, while in native apps (iPhone's Contacts app) the close button only shows up when touching the input field and disappears when closing the virtual keyboard. Touching the close button when the virtual keyboard is closed doesn't clear the input field either.

b) iPhone 4 iOS 4.3.3 1. Touch the SearchBox and start typing characters => KO, the close button doesn't show up. 2. Touch "Done" to close the virtual keyboard. => KO: the close button now shows-up, and touching it clears the input field (the virtual keyboard also opens). But in native apps (iPhone's Contacts app), the close button only shows up when touching the input field and disappears when closing the virtual keyboard.

c) HTC One X Android 4.0.4 and Samsung Galaxy Tab 10.1 Android 3.1 (same behavior on both)

  1. Touch the SearchBox and start typing characters

=> The close button is not visible (color mismatch?), however touching at its usual location does trigger a clear of the input field.

For completeness, here is how it goes on desktop browsers (which are less important than mobile browsers):

d) Desktop W7, Chrome 24

Works fine.

e) Desktop W7, Firefox 18

No close button (no compat support). Place holder ok.

f) Desktop W7, IE9

No close button and no place holder.

Attachments (1)

16672.patch (2.0 KB) - added by Douglas Hays 7 years ago.
possible fix, needs review and testing

Download all attachments as: .zip

Change History (11)

Changed 7 years ago by Douglas Hays

Attachment: 16672.patch added

possible fix, needs review and testing

comment:1 Changed 7 years ago by Adrian Vasiliu

Thanks @doughays. I've tested on the devices, and it does work a bit better on iOS6, but unfortunately it still misbehaves as follows:

a) iPhone 5 iOS 6.0.2 (and similar behavior on iPhone 4S iOS 6.0.1)

The first time you start entering text on an empty search box, the first touch of the close button clears it most of the time, but not always. Moreover, if you type again, the close button only works very rarely (once among 5 or 10 attempts). Apparently, most of the time the touch event arrives to the input field not to the button. This is particularly annoying because by default the autocorrect is enabled, thus trying to touch the close button you get the autocorrect proposal applied instead... Also, from time to time, touching the close button has the efect to move the cursor to the end/begin of the text. And the close button is still visible after closing the virtual keyboard.

The webinspector console does not show any error. The debugger shows that when touching the button doesn't clear the text it is because selectionStart is equal to value.length in this test in the patch:

if(... && this.textbox.selectionStart > this.textbox.value.length)

(but changing this into >= is not a solution because then touching anywhere clears the text).

b) iPhone 4 iOS 4.3.3

Same misbehavior as before the patch.

c) HTC One X Android 4.0.4

Same misbehavior as before the patch.

Last edited 7 years ago by Adrian Vasiliu (previous) (diff)

comment:2 Changed 6 years ago by Adrian Vasiliu

In [31269]:

refs #16672. Fixes the behavior of the close button on iOS using an evolution of a fix proposal by Frank Fortson (CLA).

comment:3 Changed 6 years ago by Adrian Vasiliu

The trouble on iOS being solved, remains the trouble on Android, which is basically that the close button is invisible when the soft keyboard is open. I've tested on different Android versions (2.x and 4.0) and different devices (HTC One X, HTC Sensation, Galaxy S3), they are all affected.

BUT this holds for the stock browser! At least on HTC One X Android 4.0.4, the issue goes away as a charm when using Chrome... A number of bugs are open against webkit in this area (although I didn't find a perfect match with our symptoms). I've tried to find a workaround for the stock browsers, but none worked well so far.

On the other side, since it works in Chrome which slowly becomes a default browser on new Android devices... Anyway, this is where we are on it.

Last edited 6 years ago by Adrian Vasiliu (previous) (diff)

comment:4 Changed 6 years ago by Adrian Vasiliu

Just to add that I think the reason of the remaining trouble on Android's stock browser is nothing else than the famous browser input overlays (the same which produce the flickering and "duplicated input field" issues in #15365). That is, the close button is invisible "simply" because it is hidden by the input overlay. Note that this overlay is on top of everything, hence playing with the z-index of the original input field doesn't help. The best known fix is... switching to other browsers.

comment:5 Changed 6 years ago by Patrick Ruzand

Owner: changed from Eric Durocher to Patrick Ruzand
Status: newassigned

comment:6 Changed 6 years ago by Patrick Ruzand

Milestone: tbd1.10

It seems to be more a theming issue than a browser issue to me: running the test on an Android device in the stock browser with the ios theme (http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/mobile/tests/test_FormControls.html?theme=ios) does show the closing button. So I would say it's a holodark theme issue.

(tested on S3/4.1.2 , S4/4.2.2 and HTC One/4.2.2.)

comment:7 Changed 6 years ago by Patrick Ruzand

definitely a styling issue, coming from the background-color:transparent coming from holodark's mblTexBox class.

As an example, the following rule does show the 'x' button: #dojox_mobile_SearchBox_0::-webkit-search-cancel-button { color: red; -webkit-appearance: none; height: 20px; width: 20px; border-radius: 10px; background: red; }

comment:8 Changed 6 years ago by Patrick Ruzand

Owner: changed from Patrick Ruzand to Damien Mandrioli

comment:9 Changed 5 years ago by Patrick Ruzand

Milestone: 1.10tbd

comment:10 Changed 4 years ago by Patrick Ruzand

Description: modified (diff)
Resolution: patchwelcome
Status: assignedclosed

Remains the android issue , which seems a styling issue. Since it only concerns the stock browser and works on Chrome for Android, it won't be fixed, unless a patch is submitted.

Note: See TracTickets for help on using tickets.