Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#1861 closed defect (wontfix)

bad dojo.string.substituteParams with ComboBox & Safari

Reported by: guest Owned by: Adam Peller
Priority: low Milestone:
Component: Widgets Version: 0.4
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by Adam Peller)

ComboBox? with dataUrl="/mason/mimetype/typeAheadLast.js?query=%{searchString}"

Version 0.3.1 worked ok with Safari 2,0(412.2). However, the searchString substition isn't working with 0.4.0.

No matter what the user types, the url is always the same (the substitution is actually text from javascript code in src/string/extras.js !)

From the Apache log:

GET /mason/mimetype/typeAheadFull.js?query=function%20(_1ce,%20key)%20%0A{%0A%20%20if%20(typeof%20map[key]%20!=%20%22undefined%22%20&&%20map[key]%20!=%20null)%0A%20%20%20%20{%0A%20%20%20%20%20%20return%20map[key];%0A%20%20%20%20}%0A%20%20dojo.raise(%22Substitution%20not%20found:%20%22+key);%0A}

Attachments (2)

dojohtml.html (624 bytes) - added by Joe 13 years ago.
html that loads the remote php file
dojoremote.php (76 bytes) - added by Joe 13 years ago.
remote php file loaded by dojo

Download all attachments as: .zip

Change History (10)

comment:1 Changed 13 years ago by Adam Peller

Description: modified (diff)
Owner: changed from bill to Adam Peller

comment:2 Changed 13 years ago by bill

Milestone: 0.4.1

comment:3 Changed 13 years ago by Adam Peller

Resolution: worksforme
Status: newclosed

Strange indeed. I'm on Safari 2.0.4 419.3 and cannot reproduce this. I simply added the %{searchString} substitution to a combobox in the tests directory along with mode="remote". It would help to have an example to reproduce this as there must be more involved to demonstrate this bug?

Changed 13 years ago by Joe

Attachment: dojohtml.html added

html that loads the remote php file

Changed 13 years ago by Joe

Attachment: dojoremote.php added

remote php file loaded by dojo

comment:4 Changed 13 years ago by Joe

Resolution: worksforme
Status: closedreopened

This bug still exists in Safari 2.0.1 and older. I tried this on 2 machines here, running 2.0.1 and 2.0. However, it's no longer a problem in 2.0.6.

I attached 2 files to show that this bug still exists in 0.4.1.

You will need to check the path for your dojo to test, but this demonstrates the problem. You should see the following in your debug dialog on the html page:

DEBUG: [SyntaxError: Parse error] DEBUG: "one","1"],["two","2"],["function (match, key) { if (typeof map[key] != "undefined" ",5?

Note that the first 2 elements in the returned JSON are valid, but the third, which should be the %{searchString} value, is actually some of the JS code (from src/string/extra.js, line 34 and on).

comment:5 Changed 13 years ago by Adam Peller

Priority: normallow
Resolution: wontfix
Status: reopenedclosed

Joe, while I'm happy to take a patch if there's an elegant solution to this, I can't invest any time in an unsupported browser (and frankly I don't have access to an old copy of Safari) We claim to support only the latest Safari "2.0.x" Sorry.

It sounds like the problem might be more simply reproduced with dojo.string.substituteParams. Safari must have not fully supported that form of the replace() function until recently?

comment:6 Changed 13 years ago by Joe

The old code (in 3.0 I think it was) worked fine, but when the code format was changed (placing an anonymous function in a replace), it broke. But, I kind of expected that answer, although I was hoping it was an easy fix that could be made quickly. I guess it was just more of a "it's not fixed" submission. But, since you changed it to "wontfix" I can't argue with that ;)

If I was a little stronger in my JS I would be glad to submit a patch, but I'm not. It's also not an isolated case as that style of code is used in a few other places that I know of as well.

It is functional in 2.0.4 and up I found out too, as are a few of the other things I've used. Don't know if that helps you make a more solid version requirement than just the latest 2.0.x.

comment:7 Changed 12 years ago by Adam Peller

Right - this function changed after 0.3.1 to use more concise (and efficient) code. Browser compatibility is a tricky business. There is likely a large matrix of bugs we've dealt with that are fixed in some recent webkit/safari, so keeping track of them may be more trouble than it's worth, but thanks for logging this information here in trac.

A patch to support specific versions would likely just bloat our code, and we've made a conscious decision not to do that, especially for the browser in question.

comment:8 Changed 12 years ago by (none)

Milestone: 0.4.1

Milestone 0.4.1 deleted

Note: See TracTickets for help on using tickets.