Search bar Firefox 24.0 space issue

[cdtweb]

Hard to explain, but I tried searching "409 Conflict" which resolves to "409+Conflict" and doesn't return any results... If I search "409" the expected result appears.. also if I put "409%20conflict".. Seems to be an encoding issue.

[commonquail]

This appears to manifest in different ways and have numerous possibly related issues. It's an issue in IE11, too (make a search provider here.

Here are a few examples I expect to take me to the page labeled "SPL/Exceptions".

FF 26.0:

• #q=:
  • spl exception: Searches for exception. Exception class.
  • spl%20exception: Searches for exception. Exception class.
  • spl/exception: Searches for spl/exception. No result.
  • splexception: Searches for splexception. No result.
• Provider:
  • spl%20exception: Searches for exception. Exception class.
  • spl exception: Searches for spl+exception. No result.
  • spl/exception: Searches for spl/exception. No result.
• Internal search:
  • spl%20exception: No result.
  • spl/exception: No result.
  • spl exception, type: Not possible. Space is ignored.
  • spl exception, paste: No result.

IE11:

• #q=:
  • spl exception: Searches for exception. Exception class.
  • spl%20exception: Searches for exception. Exception class.
  • spl/exception: Searches for spl/exception. No result.
  • splexception: Searches for splexception. No result.
• Provider:
  • spl%20exception: Searches for spl%20exception. No result.
  • spl exception: Searches for spl+exception. No result.
  • spl/exception: Variously searches for spl/exception and treats it as a URI. No result.
  • splexception: Searches for splexception. No result.
• Internal search:
  • spl%20exception: No result.
  • spl/exception: No result.
  • spl exception, type: Not possible. Space is ignored.
  • spl exception, paste: No result.
  • splexception: No result.

It seems that various special characters are not interpreted as expected by the fuzzy search, in addition to any encoding issues there may also be in place. I would expect:

• / to be treated as a literal or ignored by search.
• Spaces to be consistently stripped or allowed and possibly ignored by search.
• Query and provider arguments consistently translated to valid search terms. To this end, %20 should probably be treated as literal space.

I have no personal experience with longest common subsequence matching but I can see the rationale in ignoring spaces. However, it seems to me that a better approach would be to ignore occurrences of spaces in the search term instead of simply stripping them during input.

[Thibaut]

Thanks for the bug report. I'll look into this over the week-end.

@commonquail The "type" pages such as SPL/Exceptions aren't part of the search index (the doc also needs to be enabled for results to appear). Thanks for investigating the issue, though; this is very useful.

[commonquail]

Does that mean they can't be or aren't supposed to be, either? When I look up, say, exceptions, it's usually because I don't know if the core library includes a fitting one already or which one that would be. In that situation I can't search directly for a listing of exceptions but instead have to rely on the Alt + r shortcut from a particular result I know exists (which is nice for what it is but extra work for my poor, lazy fingers). A scoped search for exception[s] doesn't produce useful results either; far too many or too little.

tl;dr: I'd really like that but I can understand if it isn't possible.

Addendum: A possible alternative interpretation of space using the provider or the query parameter could be to delimit a search scope.

[Thibaut]

@commonquail I've opened a new issue for adding the type pages to the search index. I understand the use case but this isn't straightforward to implement.

You can already use a space the scope your search: http://devdocs.io/#q=css%20color