Closed
Bug 904464
Opened 11 years ago
Closed 11 years ago
MXR no longer handling search strings with spaces (changed to +'s)
Categories
(Webtools Graveyard :: MXR, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: ewong, Assigned: glob)
References
Details
Attachments
(1 file)
811 bytes,
patch
|
erik
:
review+
|
Details | Diff | Splinter Review |
Using http://mxr.mozilla.org/comm-central, 1) I enter "create a new account" in the search field. 2) I click search. 3) The location : http://mxr.mozilla.org/comm-central/search?string=create%2Ba%2Bnew%2Baccount but in the search for field, it shows "create+a+new+account". I need to change the + to space in order to get a proper search.
Comment 1•11 years ago
|
||
server-ops: did something MXR-related change recently?
Assignee: nobody → server-ops-devservices
Component: MXR → Server Operations: Developer Services
Product: Webtools → mozilla.org
QA Contact: nmaul
Version: Trunk → other
Updated•11 years ago
|
Summary: search strings with spaces in it are changed to +'s. → MXR no longer handling search strings with spaces (changed to +'s)
Comment 2•11 years ago
|
||
Nothing in the MXR code has changed in I don't know how long, but the OS got an update a few weeks ago. It's possible that a pkg that mxr uses is behaving differently now.
Comment 3•11 years ago
|
||
(In reply to Kendall Libby [:fubar] from comment #2) > Nothing in the MXR code has changed in I don't know how long, but the OS got > an update a few weeks ago. It's possible that a pkg that mxr uses is > behaving differently now. Perl packages change API and Behavior *all the time* when updated. Can you get a list of before and after for perl packages?
Comment 4•11 years ago
|
||
(In reply to Kendall Libby [:fubar] from comment #2) > Nothing in the MXR code has changed in I don't know how long, but the OS got > an update a few weeks ago. It's possible that a pkg that mxr uses is > behaving differently now. I see some changes at http://hg.mozilla.org/webtools/mxr/ lately, did these changes get deployed to mxr.mozilla.org?
Comment 5•11 years ago
|
||
(In reply to Frank Wein [:mcsmurf] from comment #4) > (In reply to Kendall Libby [:fubar] from comment #2) > > Nothing in the MXR code has changed in I don't know how long, but the OS got > > an update a few weeks ago. It's possible that a pkg that mxr uses is > > behaving differently now. > > I see some changes at http://hg.mozilla.org/webtools/mxr/ lately, did these > changes get deployed to mxr.mozilla.org? Indeed, and this looks very suspect since the symptom seems to be double-url-encode. http://hg.mozilla.org/webtools/mxr/rev/60adab5f668c
Flags: needinfo?(klibby)
Comment 6•11 years ago
|
||
pulling in glob as he's the author of that patch (fixing a security issue from bug 628033)
Flags: needinfo?(klibby) → needinfo?(glob)
wow, so mxr does it's own decoding of the query_string, which explicitly double-encodes pluses. it looks like there were issues with filenames with pluses (due to the lack of escaping in the header, which i fixed). there's weird workarounds for that in various locations in the code. eg. the filename in the directory head for http://mxr.mozilla.org/comm-central/source/mozilla/build/unix/stdc++compat/ is incorrect. i'll see what i can do, but my ability to test this is somewhat limited.
Assignee: server-ops-devservices → glob
Flags: needinfo?(glob)
Component: Server Operations: Developer Services → MXR
Product: mozilla.org → Webtools
QA Contact: nmaul
as best as i can tell, getting http_wash() to unescape + fixes this, and files with +'s in their name still work (eg comm-central/source/mozilla/build/unix/stdc++compat/ ) the issues with the path at the top of the mxr page wasn't related to my change, but i fixed it anyhow (it was using url escaping instead of html escaping). if there's a mxr staging environment, this should be deployed there first for testing.
Attachment #795391 -
Flags: review?
Attachment #795391 -
Flags: review? → review?(erik)
ping?
Comment 12•11 years ago
|
||
Indeed, ping. This is a quite bad regression.
Comment 13•11 years ago
|
||
Comment on attachment 795391 [details] [diff] [review] 904464_1.patch Review of attachment 795391 [details] [diff] [review]: ----------------------------------------------------------------- I'm not set up to test this either, but the code looks saner than it was. I don't know of a staging env for MXR, but if we have one, let's put it there. If not, I lean toward deploying it anyway; we can try a few hits to make sure nothing obvious is broken and roll back if we discover something more subtle.
Attachment #795391 -
Flags: review?(erik) → review+
Comment 14•11 years ago
|
||
Let's land and deploy - this is inconveniencing a lot of people.
Comment 15•11 years ago
|
||
(FYI, I'm trying to find someone who can land and deploy this)
Comment 16•11 years ago
|
||
Comment on attachment 795391 [details] [diff] [review] 904464_1.patch http://hg.mozilla.org/webtools/mxr/rev/6b92e127f403
Comment 17•11 years ago
|
||
pushed this out and cleared the cache.
Comment 18•11 years ago
|
||
Thanks to everybody that helped fix this!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•4 years ago
|
Product: Webtools → Webtools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•