Last modified: 2013-04-05 15:29:02 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 10172 - The "changed since last visit" flag is not working correctly (watchlist items bold randomly etc.)
The "changed since last visit" flag is not working correctly (watchlist items...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Watchlist (Other open bugs)
unspecified
All All
: Normal normal with 9 votes (vote)
: ---
Assigned To: Roan Kattouw
: patch, patch-need-review
: 9894 10884 12803 17688 (view as bug list)
Depends on:
Blocks: 17084
  Show dependency treegraph
 
Reported: 2007-06-06 16:51 UTC by Para
Modified: 2013-04-05 15:29 UTC (History)
14 users (show)

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


Attachments
Proposed patch (6.55 KB, patch)
2009-02-27 14:19 UTC, Roan Kattouw
Details
Improved patch (6.50 KB, patch)
2009-03-02 11:35 UTC, Roan Kattouw
Details
More improvements (6.51 KB, patch)
2009-03-02 11:40 UTC, Roan Kattouw
Details
Patch v4 (6.26 KB, patch)
2009-03-02 12:01 UTC, Roan Kattouw
Details

Description Para 2007-06-06 16:51:20 UTC
The "Pages which have been changed since you last visited them are shown in bold" feature of Special:Watchlist broke on Commons and Meta at some point during the last few days.

Some pages changed after my last visit are not bold, and some that I have visited after the latest change are still in bold. All my watched and changed pages seem to be correctly bolded in Recent Changes however. Both the expanded and normal watchlist show this bug. The <strong> tag or its absence seems random.

I don't see any pattern to this, and apparently it's only happening to some users, not all. See also <http://commons.wikimedia.org/wiki/Commons:Help_desk#Changes_don.27t_get_marked>.
Comment 1 brianna.laugher 2007-06-09 12:26:08 UTC
The problem is not that they are bold "at random", but they are not bold consistently as they used to be. It used to be pages you hadn't read since the last edit on that page would be bold. They would go non-bold after you visited the page. Now, there can be new changes you haven't read yet, but the page listing isn't bold as it should be according to the previous behaviour.
Comment 2 Para 2007-06-09 21:16:31 UTC
It's working ok for me again. What happened?? Will it happen again?
Comment 3 brianna.laugher 2007-06-10 09:38:57 UTC
Seems to be fixed now. Easy solution. ;)
Comment 4 Jeff G. 2007-06-14 16:03:48 UTC
It does not seem to be fixed for me now. :(
Comment 5 Para 2007-07-11 11:16:58 UTC
Indeed, the problem is back for me too. (Commons:User:Para)

The last few days I've had the watchlist lag behind some minutes, ie. updated pages I haven't seen yet are listed at the top of the watchlist, but not in bold until some moments of wait.

Today it seems to have turned into "random" again, with no logic in which unseen pages are listed in bold. If I visit one of the bolded pages, it correctly turns not-bold, but it's the unseen not-bold pages that are making it hard to stay up to date with changes.
Comment 6 Mormegil 2007-08-19 15:47:48 UTC
The problem is that the on-edit update (mark the page as modified) is postponed to the job queue (if $wgEnotifUseJobQ is set, which probably is), but the on-view update (clear the modified flag on the page) is executed immediately during page view. That means that 1. your edits are always displayed bold, 2. if you view a page too soon after the respective change, that visit is ignored (since it is overwritten a bit later by the postponed EnotifNotifyJob) and you need to revisit it to clear the flag, 3. very recent edits are shown non-bold on top of the watchlist, and then, suddenly, become bold, as the postponed job is executed.

This is obviously broken: because the implementation using wl_notificationtimestamp being NULL/non-NULL is dependent on the order of operations, the operations need to be executed in the correct order, which they currently are not.

I can see a few options how to solve this:
1. Switch $wgEnotifUseJobQ off, so that it works at least. (But, the code would still be broken, and there could be some performance implications.)
2. Do not postpone wl_notificationtimestamp to the work queue and do it right away in notifyOnPageChange. (Are there any real performance implications in that, provided that the whole change-notification business is disabled on the large wikis, IIANM?)
3. Move viewUpdate() to the job queue, too. (Kinda silly, and the problem #3 above would still hold, but at least it would work a little bit more deterministically and the ordering would be correct. Also: creating a job for every page view is probably a _really_ silly thing to do…)
4. Implement the whole thing a little bit better. One idea that wouldn't need so much work would be to store both the last-visit and last-update timestamps separately, so that the operations wouldn't need the correct ordering (they could detect that the on-edit job is obsolete and ignore it, etc.). (You could even get without the last-update column completely, since the information is stored in the page history…) You could even do without a schema change with a small hack: store +timestamp for a timestamp of a non-visited edit, and -timestamp for a timestamp of the last visit to a page that has not yet been changed since that.
Comment 7 Mormegil 2007-08-19 15:48:23 UTC
*** Bug 10884 has been marked as a duplicate of this bug. ***
Comment 8 Mormegil 2007-08-19 15:48:38 UTC
*** Bug 9894 has been marked as a duplicate of this bug. ***
Comment 9 Mormegil 2007-08-19 18:58:37 UTC
Changing summary so that it expresses the bigger scope better.
Comment 10 Carl Fürstenberg 2008-02-02 01:00:25 UTC
If this feature cannot be fixed, I would ask to have it deactivated, at least on my accounts, as it's pretty useless, distracting and thus an unnecessary server drain.
Comment 11 Ciell 2008-04-25 09:58:14 UTC
When fixing, could it be added as a setting in preferences as well? I do not see the additional value on wiki's I'm highly active.
Comment 12 Jelte (WebBoy) 2008-05-01 10:40:15 UTC
(In reply to comment #11)
> When fixing, could it be added as a setting in preferences as well? I do not
> see the additional value on wiki's I'm highly active.
> 

Added as bug 13910
Comment 13 Siebrand Mazeland 2009-02-02 11:42:13 UTC
Changing component to "Watchlist"
Comment 14 Danny B. 2009-02-26 22:05:58 UTC
*** Bug 17688 has been marked as a duplicate of this bug. ***
Comment 15 Roan Kattouw 2009-02-27 12:35:17 UTC
(In reply to comment #6)
> 2. Do not postpone wl_notificationtimestamp to the work queue and do it right
> away in notifyOnPageChange. (Are there any real performance implications in
> that, provided that the whole change-notification business is disabled on the
> large wikis, IIANM?)
I think that's the way to go; I'll post a patch for this later today.
Comment 16 Roan Kattouw 2009-02-27 14:19:50 UTC
Created attachment 5868 [details]
Proposed patch

The attached patch aims to fix this bug by:
* moving up the UPDATE on wl_notificationtimestamp to before the EnotifNotifyJob is scheduled
* moving up the query fetching the users to be notified before that, because it needs the old value of wl_notificationtimestamp
* passing actuallyNotifyOnPageChange() and the EnotifyNotifyJob an array of user IDs
* adding UserArray::newFromIDs()
Comment 17 Roan Kattouw 2009-03-02 11:35:04 UTC
Created attachment 5873 [details]
Improved patch

Removed useless JOIN on user table, thanks to Tim for spotting it.
Comment 18 Roan Kattouw 2009-03-02 11:40:35 UTC
Created attachment 5874 [details]
More improvements

Casting $ids to an array, avoiding empty(), returning an empty array instead of null.
Comment 19 Roan Kattouw 2009-03-02 12:01:19 UTC
Created attachment 5875 [details]
Patch v4

...and more improvements:
* Run the SELECT query on the master
* Use the result of the SELECT query for the UPDATE query
* Fix a $row->user_id reference
* Use new ArrayIterator(array()) instead of array() in UserArray::newFromIDs()
Comment 20 Roan Kattouw 2009-03-02 12:16:31 UTC
(In reply to comment #19)
> Created an attachment (id=5875) [details]
> Patch v4
> 
> ...and more improvements:
> * Run the SELECT query on the master
> * Use the result of the SELECT query for the UPDATE query
> * Fix a $row->user_id reference
> * Use new ArrayIterator(array()) instead of array() in UserArray::newFromIDs()
> 

Slightly modified version of this patch committed in r47927.
Comment 21 T. Gries 2009-03-02 12:58:42 UTC
marking "blocks 17084" bug
Comment 22 T. Gries 2009-03-02 13:00:09 UTC
reopened the 10172, because this problem is ongoing (again present) since January 2009.
Comment 23 Roan Kattouw 2009-03-02 16:28:54 UTC
(In reply to comment #22)
> reopened the 10172, because this problem is ongoing (again present) since
> January 2009.
> 

I committed a patch that should fix this issue a few hours ago, see comment #20. Reclosing as FIXED.
Comment 24 Yann Forget 2009-04-02 15:09:44 UTC
Not fixed, see http://commons.wikimedia.org/wiki/Commons:Village_pump#Mysterious_fontbolding
This bug is still there for me too.
Comment 25 Ilmari Karonen 2009-04-20 18:00:07 UTC
As Mormegil notes in comment #6, the problem is that the whole feature has been designed ass-backwards.  Any design that requires the code to update a bazillion watchlist records whenever a busy and popular page changes is not going to scale well.  It's not as if it should be difficult to do it the right way (store last visit timestamp in watchlist, compare with last update timestamp in page/recentchanges table).
Comment 26 Mormegil 2009-04-20 19:15:47 UTC
OK, comment #25 might be correct, but the fix committed in r47927 might work, but it contains a terrible bug, AFAICT, which makes the result worse than the original problem.

See my comment at http://www.mediawiki.org/wiki/Special:Code/MediaWiki/47927#c2262
Comment 27 Roan Kattouw 2009-04-21 09:38:20 UTC
(In reply to comment #26)
> OK, comment #25 might be correct, but the fix committed in r47927 might work,
> but it contains a terrible bug, AFAICT, which makes the result worse than the
> original problem.
> 
Oops, that would be totally my fault. Seems to have been fixed in r49682, though, I'll push for that rev to go live.
Comment 28 T. Gries 2009-04-21 17:19:32 UTC
> (In reply to comment #26)
> Oops, that would be totally my fault. Seems to have been fixed in r49682,
> though, I'll push for that rev to go live.

I really appreciate that you reintroduced that _core_ piece of my algorithm.
Tom
Comment 29 Tim Starling 2009-05-01 06:13:26 UTC
Deployed r49682 on Wikimedia and backported to 1.15. 
Comment 30 Andre Klapper 2013-04-05 15:29:02 UTC
*** Bug 12803 has been marked as a duplicate of this bug. ***

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


Navigation
Links