Opened 8 years ago
Closed 8 years ago
#15969 closed defect (fixed)
[regression] ComboBox: dropdown highlighting for autocomplete incorrect for IE 8 browser
Reported by: | Stan Cason | Owned by: | Douglas Hays |
---|---|---|---|
Priority: | blocker | Milestone: | 1.8.1 |
Component: | Dijit - Form | Version: | 1.8.0 |
Keywords: | Cc: | Colin Snover | |
Blocked By: | Blocking: |
Description
I noticed strange behavior of the combobox dropdown highlighting when moving to version 1.8. I ran the example demo and saw that it happens in the demo on IE 8.
http://dojotoolkit.org/documentation/tutorials/1.8/selects/demo/FilteringSelect.php
I type in Al in the autocomplete and get Alabama Alaska
in the drop down list.
Attachments (3)
Change History (13)
Changed 8 years ago by
Attachment: | digit.form.FilteringSelect.jpg added |
---|
comment:1 Changed 8 years ago by
Component: | Dijit → Dijit - Form |
---|---|
Owner: | changed from bill to Douglas Hays |
Summary: | ComboBox dropdown highlighting for autocomplete incorrect for IE 8 browser → ComboBox: dropdown highlighting for autocomplete incorrect for IE 8 browser |
comment:2 follow-up: 5 Changed 8 years ago by
Cc: | Colin Snover added |
---|---|
Component: | Dijit - Form → BuildSystem |
Owner: | changed from Douglas Hays to Rawld Gill |
This seems to be a build problem. Not sure if it's a blocker or not. In _AutoCompleterMixin.js::doHighlight, a replace is performed using this text:
'\uFFFF$1\uFFFF'
but some process between build and runtime is interpreting these as invalid characters and modifying them (to \uFFFD), but the following regexp with the same characters that is supposed to undo them is not modified and so the invalid UTF characters remain. The actual character used is unimportant since they're meant to be temporary but they need to be guaranteed to not be present in the original text and \uFFFF is supposedly such a character. ComboBox? continues to work just fine but the popup menu of items is messed up visually (apparently only on IE). Unbuilt code seems to work fine on all browsers.
comment:3 Changed 8 years ago by
Priority: | undecided → blocker |
---|---|
Status: | new → assigned |
If it is a regression, works unbuilt, but breaks built, it needs to block. Setting blocker assuming that is the case here, rcgill can reassign if it is not.
comment:4 Changed 8 years ago by
Same failure with IE9 running examples on http://livedocs.dojotoolkit.org/dijit/form/ComboBox
comment:5 Changed 8 years ago by
Owner: | changed from Rawld Gill to Douglas Hays |
---|
Replying to doughays:
I did a build and the nonoptimized code looks fine, so I don't think our builder is the direct problem. However, when I inspected a shrinksafe optimized layer (e.g., dojo/dijit-all.js), I see the characters mangled. closure seems to do OK.
I played a bit and found that shrinksafe would be ok if
"\uFFFF$1\uFFFF"
was replaced with
String.fromCharCode(0xffff, 0x24, 0x31, 0xffff)
I didn't check in a fix as I'd like someone more familiar with the code path to look at this suggestion.
otoh, if you still think it is something before the optimizer, please tell me the build command you are using and the file I should look at.
comment:6 Changed 8 years ago by
Component: | BuildSystem → Dijit - Form |
---|---|
Summary: | ComboBox: dropdown highlighting for autocomplete incorrect for IE 8 browser → [regression] ComboBox: dropdown highlighting for autocomplete incorrect for IE 8 browser |
So it's a shrinksafe bug that we presumably won't fix, since we'll presumably drop shrinksafe for 2.0. It would be easy to mark as wontfix but since it's a regression I suppose we should check in something like Rawld's workaround.
comment:7 Changed 8 years ago by
Shrinksafe (via Java) is transcoding the string text \uFFFF (6 ASCII bytes) to the shorter UTF-8 characters EF BF BF (3 bytes). But \uFFFE and \uFFFF and reserved by the Unicode as for private use and are listed as non-characters and should not be transcoded. Refer to http://en.wikipedia.org/wiki/Mapping_of_Unicode_characters#Private_use_characters. This is somewhat the same as #5027 in which the null character was forced to be escaped within Shrinksafe. rcgill's JS workaround is sufficient but I would recommend fixing Shrinksafe by adding similar exceptions for 0xFFFE and 0xFFFF as well. Since we're dropping Shrinksafe and it's not a problem in the closureCompiler I'd hate to munge the JS code that will remain beyond Shrinksafe.
Changed 8 years ago by
Attachment: | shrinksafe.jar added |
---|
proposed fix replacing util/shrinksafe/shrinksafe.jar
comment:9 Changed 8 years ago by
Milestone: | tbd → 1.8.1 |
---|
Changed 8 years ago by
Attachment: | 15969.patch added |
---|
Example Screen Shot