Closed Bug 564595 Opened 15 years ago Closed 12 years ago

javascript don't remove \" in variable

Categories

(Firefox :: General, defect)

3.6 Branch
x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: webmaster, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 when executing document.getElementById("pubprod").innerHTML = prod[1]; where prod[1] = "Radiateur huile<br /><a rel=\"nofollow\" href=\"/Dirt-Bike|9/Pieces-Detachees-Dirt|43/Motorisation|45/Haut-moteur|96/Radiateur-huile-ctgnb96-pdn1302.html\"><img src=\"/photos/th140_100321_195016tWe/Radiateur-huile.png\" alt=\"Radiateur huile\" width=\"80\"></a><br />25.50&nbsp;&euro; !"; the firefox try to load: /%5C%22/photos/th140_100321_195016tWe/Radiateur-huile.png%5C%22 %5C%22 = \" was not here before... Reproducible: Sometimes Actual Results: load the page http://www.pocketmotors.fr/Dirt-Bike|9/index.html and check the rool image on the right
I am seeing what looks like the same problem. The SonicWALL firewall appliance's web server has numerous pages that include this: document.write('<img border=\"0\" src=\"firstPage.gif\" width=\"16\" height=\"16\">'); When this is processed by recent Firefox versions (3.6) it results in an HTTP get as follows (captured using WireShark) resulting in a failure to fetch the file: GET /%5C%22firstPage.gif%5C%22 HTTP/1.1 If I change each \" to " in the above then it fetches the file correctly. Note that although using \" in the JavaScript here is not needed, it is not actually wrong to do so and \" should be interpreted as a ". I'm pretty sure that this has only starting happening with recent versions of Firefox.
Note that there do seem to be subsequent correct fetches of the files after the failures, as shown in the following WireShark trace, and so these gifs do display properly, it’s just rather slow to render the pages due to this. No. Time Source Destination Protocol Info 1488 14.987145 192.168.168.1 192.168.168.40 HTTP GET /blank.gif HTTP/1.1 1490 14.987401 192.168.168.1 192.168.168.40 HTTP GET /swlTutorial.js HTTP/1.1 1505 14.998298 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (application/x-javascript) 1518 15.003052 192.168.168.1 192.168.168.40 HTTP GET /%5C%22firstPage.gif%5C%22 HTTP/1.1 1519 15.003109 192.168.168.1 192.168.168.40 HTTP GET /%5C%22prevPage.gif%5C%22 HTTP/1.1 1526 15.018003 192.168.168.1 192.168.168.40 HTTP GET /%5C%22nextPage.gif%5C%22 HTTP/1.1 1541 15.048809 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (GIF89a) 1547 15.049060 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (application/x-javascript) 1558 15.051300 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (application/x-javascript) 1568 15.057173 192.168.168.1 192.168.168.40 HTTP GET /%5C%22lastPage.gif%5C%22 HTTP/1.1 1569 15.057233 192.168.168.1 192.168.168.40 HTTP GET /%5C%22upArrow.gif%5C%22 HTTP/1.1 1573 15.063607 192.168.168.1 192.168.168.40 HTTP GET /%5C%22downArrow.gif%5C%22 HTTP/1.1 1586 15.092902 192.168.168.1 192.168.168.40 HTTP GET /edit.gif HTTP/1.1 1600 15.105267 192.168.168.1 192.168.168.40 HTTP GET /trash.gif HTTP/1.1 1601 15.105357 192.168.168.1 192.168.168.40 HTTP GET /checkMark.gif HTTP/1.1 1614 15.138754 192.168.168.1 192.168.168.40 HTTP GET /firstPage.gif HTTP/1.1 1620 15.144344 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (GIF89a) 1627 15.144764 192.168.168.1 192.168.168.40 HTTP GET /prevPage.gif HTTP/1.1 1630 15.144948 192.168.168.1 192.168.168.40 HTTP GET /nextPage.gif HTTP/1.1 1634 15.145435 192.168.168.1 192.168.168.40 HTTP GET /lastPage.gif HTTP/1.1 1636 15.167296 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (GIF89a) 1641 15.173429 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (GIF89a) 1648 15.183953 192.168.168.1 192.168.168.40 HTTP GET /upArrow.gif HTTP/1.1 1650 15.192462 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (GIF89a) 1656 15.193125 192.168.168.1 192.168.168.40 HTTP GET /stat.gif HTTP/1.1 1663 15.216837 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (GIF89a) 1669 15.217219 192.168.168.1 192.168.168.40 HTTP GET /trashx.gif HTTP/1.1 1672 15.232621 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (GIF89a) 1678 15.235753 192.168.168.1 192.168.168.40 HTTP GET /table_column_back_tall.gif HTTP/1.1 1680 15.239289 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (GIF89a) 1684 15.250303 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (GIF89a) 1689 15.265605 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (GIF89a) 1692 15.265737 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (GIF89a) 1699 15.280216 192.168.168.40 192.168.168.1 HTTP HTTP/1.0 200 OK (GIF89a) Also note that it appears that our web server is not returning any reply to the erroneous gets which probably explains the slow rendering of the pages.
Version: unspecified → 3.6 Branch
This seems to work here. Please reopen if it's still an issue for you, though.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.