User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36 Steps to reproduce: I was looking for Node.insertBefore and entered insertbefore into the search. Yields https://developer.mozilla.org/de/search?q=insertbefore Actual results: The result (Node.insertBefore) wasn't shown. Expected results: Case insensitive results should have been shown as well or, alternatively, a hint should be placed somewhere, that some results maybe weren't displayed due to case sensitivity of search engine. Compare above result page with https://developer.mozilla.org/de/search?q=insertBefore
Component: General → General
Product: Developer Documentation → Mozilla Developer Network
Sheppy and I can confirm this. :jezdez may know what's happening. Is this by design?
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: General → Search
Ever confirmed: true
I hope this isn't by design, because requiring case-sensitive matches is going to really hamper good search results. It also explains many things about past search results I've seen. :)
This is an interesting combination of things, 1) Since the OP searched on the German locale the search scoring takes it into account. It ranks all documents not in that language a tiny bit lower which means that English-only documents like the Node.insertBefore() are ranked lower. This is intended to make sure that the relatively small number of translated documents get enough attention in the search results. 2) As a result of 1) you'll find the Node.insertBefore() document on the 2nd search result page as the first item (for me, at the date of this comment, https://developer.mozilla.org/de/search?q=insertbefore&page=2). 3) The document https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/insertbefore is ranked highest because it's an exact match for the search query, also intended behaviour. 4) Looking at the English results (https://developer.mozilla.org/en-US/search?q=insertbefore) you'll see that the Node.insertBefore() page is ranked higher because it misses the negative boost from 1). Again the Tech/XUL/Attribute/insertbefore document is on result position 1 due to an exact match. To answer the actual question, no the search is not case sensitive, but it's content sensitive and looks at various data to do the scoring. That includes (I may miss something) the following with the amount of how much it affects a base score of 1.0: - the title: 1.2 - an exact match in the title: 6.0 - an exact match in the summary: 2.0 - an exact match in the content: 1.0 (no-op basically, I think we changed that post-launch) - an exact phrase match in the title: 10.0 - an exact phrase match in the content: 6.0 - if the document is a zone: 8.0 - if the document is a first level document: 4.0 - any document not with the current requests language: -0.5 All of these conditions are used when calculating the score for each document in the search result.
Given that the algorithm is working as-designed, I'm bumping this down to minor.
Severity: major → minor
I was searching for window.matchMedia and discovered that this page > https://developer.mozilla.org/en-US/search?q=matchmedia returns 2 results, but this one > https://developer.mozilla.org/en-US/search?q=matchMedia has 2332. So I think this is a pretty big problem.
You need to log in before you can comment on or make changes to this bug.