Regarding other browsers:
  Safari 4 - FAIL, Opera 10 - FAIL, Firefox 3 - OK, IE 7/8 - FAIL (and Chrome - FAIL)

One response to this issue is that according to http://www.ietf.org/rfc/rfc2396.txt 
backslash characters are not valid characters in URLs so how Firefox handles invalid 
URL characters (including the backslash) may not be the way Chrome and other browsers 
handle the backslash.  All other browsers tested in this comment convert the 
backslash into forward slashes.

Technically, if you required backslash characters in your URL you need to encode them 
using %5C.  The above URL with the backslashes encoded is:
   http://texify.com/$x=%5Cint{-b%5Cpm%5Csqrt{b^2-4ac}$

In fact, the above URL with all invalid characters encoded properly would be:

   http://texify.com/$x=%5Cint%7B-b%5Cpm%5Csqrt%7Bb%5E2-4ac%7D$

However, the other response is that there is one problem that is only in Chrome.

When going to the fully encoded URL given in Comment 2, Chrome will update the 
Omnibox URL with the decoded characters.  However, if you then highlight the Omnibox 
URL and Copy it, then Paste it again it shows as: 
   http://texify.com/$x=/int%7B-b/pm/sqrt%7Bb%5E2-4ac%7D$

This problem is only in Chrome.  Firefox will preserve the backslashes, and the other 
browsers do not redisplay the decoded characters but keep the character encodings.

There is definitely a Chrome only bug that "Chrome converts every backslash in the 
URL into forward slashes".

Well, it was not my intention to report this exactly as a bug but as an "inconvenient
feature"

AFAIK that RFC does not force any browser to especifically replace backslashes with
forward ones. IMHO "\" would be better replaced with "%5C" than with "/" in the same
way as " " is replaced with "%20" or "{" is replaced with "%7B".

I know that inserting Latex strings in URLs could sound weird. But "/" is not the
same as "\" and maybe when a user writes "\" he means "\" ("%5C"). 

Concerning #3, I would not call that a bug. Every browser shows the "%20"
replacements in the address bar, I don't see the point of hiding the slash replacements. 

Comment #3 is definitely a bug.

Every other browser except Firefox shows the encoding replacements (maintaining %5C for 
the backslashes) which is fine.  Firefox shows the decoded characters but preserves the 
backslashes when copying and pasting, which is also fine.

Chrome also shows the decoded characters but changes backslashes to forward slashes 
after copying and pasting, which is a bug.

(No comment was entered for this change.)

I've looked into it a bit - looks like it's converted by googleurl's path 
canonicalizer.  In googleurl/src/url_canon_path.cc there's a line that silently 
converts backslashes to forward slashes.  It won't be very hard to fix it (e.g. make 
it optional), but I'm not sure how I can change the code in googleurl.

Area-UI-Features label replaces Area-BrowserUI label

(No comment was entered for this change.)

(No comment was entered for this change.)