Last modified: 2008-07-25 16:48:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14659 - limit=50 on RC gives count set in preferences, not 50
limit=50 on RC gives count set in preferences, not 50
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-27 00:08 UTC by Robert Ullmann
Modified: 2008-07-25 16:48 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Robert Ullmann 2008-06-27 00:08:01 UTC
If (e.g.) I set number of changes to be displayed in RC in preferences to 470, then clicking on "50" in the RC display or explicitly setting &limit=50 in the url gives me 470.

Someone has used "=50" to mean "=default selected"?

Observed on en.wikt, confirmed by another user.
Comment 1 Splarka 2008-06-27 00:38:59 UTC
Note that subpage syntax behaves as expected, eg: Special:RecentChanges/50 actually shows 50 instead of User::getDefaultOption( 'rclimit' )
Comment 2 Chris McKenna 2008-06-28 22:08:00 UTC
I've just tested this and I'm seeing the same on commons, en.wp and cy.wp.
Setting the default to less than 50 produces an identical result.
Comment 3 Robert Ullmann 2008-06-29 14:13:48 UTC
The "new helper class" FormOptions is causing the problem.

Caller (e.g. Special RC, but also others), has already set user default in $opts, wants this routine to override with specified values from the request.

This routine (fetchValuesFromRequest) should always set the array element, even if it is the "default". There is no reason for this check (it is trying to save an assignment? ;-) Code:

            if ( $value !== $default && $value !== null ) {
                $this->options[$name]['value'] = $value;
            }

should be changed to:

            if ( $value !== null ) {
                $this->options[$name]['value'] = $value;
            }

(the null check also seems odd; it means a request can't override the default with null? Seems to me case INTNULL needs that? Dunno.)

(meta comment: IMHO creating new "helpful" classes to just bury code deeper always risks this sort of thing; the code in the various callers was doing just fine. But never mind.)
Comment 4 Alexandre Emsenhuber [IAlex] 2008-07-25 16:48:16 UTC
fixed in r38036.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links