https://bugzilla.wikimedia.org/show_bug.cgi?id=48568

Brad Jorsch <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #8 from Brad Jorsch <[email protected]> ---
(In reply to comment #6)
> There's no API request involved.

That's not entirely true. The number itself is served with the page, yes, but
the "flyout" is done with an API request to fetch the actual messages. And then
a second API request is performed to mark the messages as read, based on what
was returned by the first request. And I note that both of these are sent as
GET requests and don't seem to set any additional caching-related headers on
the request, and the responses don't seem to do anything special cache-wise
either, meaning it is very likely that some browsers will cache them in at
least some configurations. I'm not familiar with IE configuration, but I
imagine that adjusting the caching settings to their most aggressive values
would allow you to reproduce the bug.

If the browser or proxy responds to the first request from cache, that would
certainly cause what SandyGeorgia reports. And the cached data would also cause
the "mark read" query to not include the ids that are actually unread, so they
wouldn't get marked as read and the number would remain for later pageviews as
is reported here. Off the top of my head, one way around that would be to
include some data attribute on the notification badge with the id or timestamp
of the most recent notification, and use that value as a cache buster on the
API request.

Further, once the first request is served from cache, the second will probably
be served from cache too since it will have the same value for 'notmarkread' as
was sent the first time. While fixing the caching issue in the first would
prevent this anyway, I do note that this second query should be a POST rather
than a GET since it is intended to change state on the server.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to