Page MenuHomePhabricator

Filew/fileh search is broken (always truncated to 1 digit)
Closed, ResolvedPublic8 Estimated Story Points



Screenshot_20180403_133746.png (435×743 px, 86 KB)

After re-opening the form
Screenshot_20180403_133757.png (168×736 px, 12 KB)

Bug description

  • Open the "advanced parameters".
  • Select a file type, e.g. "jpg".
  • Enter either a with, height, or both. Make sure you enter numbers with more than one digit, e.g. "123".
  • Submit.
  • Notice the URL contains search=…+filew:>123&…. This is correct and the reason why the search result is the expected one.
  • But the URL also contains advancedSearch-current={"options":{"filew":[">":"1"]}}. The number here is truncated and only shows the first digit.
  • This is reflected in the form.

Adding one more observation:

  • the information is lost in the form so if we would conduct a new search we'd get different results.

I tried to dig into this and found that all change events except the first one are lost on all 4 file width/height input elements.


  • The two affected fields (ImageDimensionInput) are homebrewn fields that consist of 2 other OOUI elements
  • There is code in ImageDimensionInput that tries to connect the change events of the two operatorInput and valueInput to properly propagate to the store.
  • The change event seems to only listen to the first input, not to any changes after that. However, the correct value appears in the url.
  • There are no unit tests for ImageDimensionInput so far, and they should definitely be added

When a number like "1234" is entered into the px field, and then we search,

  • the search results should be correct
  • the search form should still have the same number in the px field
  • there should not be any new params in the search bar
  • the url should not have any unexpected parameters
  • this should work for all px fields in all combinations

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Related issues that lead to this report:

  • I can not update my local MediaWiki any more. I get a sequence of "fatal: protocol error: bad pack header".
  • I don't have access to Why is it so heavily protected in the first place?

I can not update my local MediaWiki any more. I get a sequence of "fatal: protocol error: bad pack header".

This apparently happens every time we delete old wmfXX branches in Gerrit, and is resolved by running git remote prune origin/git remote prune gerrit to remove your local references to those branches. I ran into this myself a few days ago and learned the solution from Chad.

I was able to update my system, thank you very much @matmarex! Unfortunately the OOUI issue remains unaffected, even with the most recent OOUI 0.26.1.

New issue: now gives a 404.

Lea_WMDE updated the task description. (Show Details)
Lea_WMDE set the point value for this task to 8.
Lea_WMDE moved this task from Backlog to Tickets ready for pickup on the Advanced-Search board.

Change 424360 had a related patch set uploaded (by Gabriel Birke; owner: Gabriel Birke):
[mediawiki/extensions/AdvancedSearch@master] Make SearchModel immutable

Change 424612 had a related patch set uploaded (by Gabriel Birke; owner: Gabriel Birke):
[mediawiki/extensions/AdvancedSearch@master] Split AdvancedOptionsBuilder

Change 425081 had a related patch set uploaded (by Gabriel Birke; owner: Gabriel Birke):
[mediawiki/extensions/AdvancedSearch@master] Add defaults to search fields

gabriel-wmde moved this task from Doing to Review on the WMDE-FUN-Sprint-2018-04-04 board.

Change 424360 merged by jenkins-bot:
[mediawiki/extensions/AdvancedSearch@master] Make SearchModel immutable

Change 424612 merged by jenkins-bot:
[mediawiki/extensions/AdvancedSearch@master] Split AdvancedOptionsBuilder

Change 425081 merged by jenkins-bot:
[mediawiki/extensions/AdvancedSearch@master] Add defaults to search fields

The URL is still weird, such as: filetype%22%3A%22bitmap%22%2C%22filew%22%3A%5B%22%3C%22%2C%224321%22%5D%2C%22fileh%22%3A%5B%22%3C%22%2C%224321%22%5D%7D%2C%22namespaces%22%3A%5B%224%22%2C%226%22%2C%227%22%2C%2212%22%5D%7D&ns4=1&ns6=1&ns7=1&ns12=1&searchToken=4dvggsg5rvw11tcxq6xzkelmz

In decoded form, this URL looks like …?search=filetype:bitmap+filew:<4321+fileh:<4321&title=Spezial:Suche&profile=advanced&fulltext=1&advancedSearch-current={"options":{"filetype":"bitmap","filew":["<","4321"],"fileh":["<","4321"]},"namespaces":["4","6","7","12"]}&ns4=1&ns6=1&ns7=1&ns12=1&searchToken=….

What is particularly "weird" about this?

In my opinion there is not much room for optimization in this URL. All the parameters are needed for one reason or the other. A few possibly optimizations I can see:

  • Get rid of the namespace array in the options, and exclusively use the &ns…=1 parameters for this.
  • Serialize the filew and fileh options as strings. Instead of ["<","4321"] (which becomes %5B%22%3C%22%2C%22…%22%5D when encoded) it will be "<4321" then (encoded %22%3C…%22).

Unrelated: How do I get access to this test wiki?