I assume that you're not logged into Wikipedia when that happens, right? Just to clarify the report.

No I am not logged in most times, I only made an account to complain about the Media Viewer, so I have no need to be.

Thanks for taking the time to report this!

I always use https: connections, never anything else.

I presume you always use the same domain as well? There is no way to make browsers store data for multiple domains, so if you disable on en.wikipedia.org and go to de.wikipedia.org, you have to disable again - that's a security limitation that we have no realistic way of circumventing.

Apart from that, the settings should stick forever. They use localStorage, not cookies - the two mostly behave the same, but there are a few differences. A few things two check:

• please test your localStorage quota here and how much space is used by running encodeURIComponent(JSON.stringify(localStorage)).length. Theoretically running out of space should not cause anything like this (setting a value in localStorage should either fail immediately or last indefinitely) but still worth checking.
• do you see any pattern in when the settings are lost? Does it correlate to the deploy cycle? MediaWiki uses localStorage to cache javascript files, maybe that pushes other content out somehow (although again that should not happen).
• please try to set something unrelated to MediaViewer in localstorage and see if it shows the same behavior. The easiest way is to enable web font downloading in the language selector and seeing if it sticks for several weeks. (According to the spec User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. Most browsers do that, but mobile Safari is known to ignore the spec in some cases, especially if it is running out of disk space. I haven't found anything definite about desktop Safari.)

If someone can't fix this issue then perhaps I should find someone to make Firefox, Chrome and Safari plugins to kill the Media Viewer so it's never seen? I'm sure there's a way to do it.

Benlisquare had mentioned writing a Greasemonkey script, you could ask him about that. But it's trivial to write another one, too, just execute mw.config.set('wgMediaViewerOnClick', false); at some point after the MediaWiki startup module has loaded.

Maybe, this stuff is just getting displaced out of LocalStorage by ResourceLoader?

Theoretically, localStorage contents should not be displaced, the browser should just throw an exception if you are trying to add new content and run over quota - it's more like a database than a cache in that regard. But in practice that's certainly one thing to look at.

In T85923#958186, @Tgr wrote:

Thanks for taking the time to report this!

I always use https: connections, never anything else.

I presume you always use the same domain as well? There is no way to make browsers store data for multiple domains, so if you disable on en.wikipedia.org and go to de.wikipedia.org, you have to disable again - that's a security limitation that we have no realistic way of circumventing.

Apart from that, the settings should stick forever. They use localStorage, not cookies - the two mostly behave the same, but there are a few differences. A few things two check:

• please test your localStorage quota here and how much space is used by running encodeURIComponent(JSON.stringify(localStorage)).length. Theoretically running out of space should not cause anything like this (setting a value in localStorage should either fail immediately or last indefinitely) but still worth checking.
• do you see any pattern in when the settings are lost? Does it correlate to the deploy cycle? MediaWiki uses localStorage to cache javascript files, maybe that pushes other content out somehow (although again that should not happen).
• please try to set something unrelated to MediaViewer in localstorage and see if it shows the same behavior. The easiest way is to enable web font downloading in the language selector and seeing if it sticks for several weeks. (According to the spec User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. Most browsers do that, but mobile Safari is known to ignore the spec in some cases, especially if it is running out of disk space. I haven't found anything definite about desktop Safari.)

I always go to the en.wikipedia.org site, I only end up elsewhere by accident.

The behaviour of the bug is as follows: I use Wikipedia a few times a week. Using the same link to the en.wikipedia.org "main page."

At random intervals from a few days to a few weeks when I happen to click on an image the Media Viewer comes up despite my supposedly deactivating it. I quit the browser (Safari) after I am done using it, and the computer usually gets shut down a few times in a week.

There doesn't appear to be any logic to it. I click on an image and most times it's displayed properly... but sometimes the Media Viewer comes up.

Since I don't delete cookies or browser data, at least not the wikipedia related ones, I don't understand why this happens.

I am just a regular Wikipedia user, I have no clue what encodeURIComponent... etc is or how to run it. I am not familiar with coding or browser ins and outs. I am just tired of having to insist on not having to use the Media Viewer when I have already opted out, many times by now. There's no efficient method of providing feedback regarding issues that users experience, and it's a recurring albeit unpredictable bug...

So here I am.

I am just a regular Wikipedia user, I have no clue what encodeURIComponent... etc is or how to run it.

I don't use Safari myself but googling it says that you can open the console with Option+Cmd+C. After that just copy/paste encodeURIComponent(JSON.stringify(localStorage)).length in the window that opened and press enter.

There's no efficient method of providing feedback regarding issues that users experience, and it's a recurring albeit unpredictable bug...

Not sure about efficient, but the most effective way is always using the bug tracker; and you are the first person who reported this in the 6 months since anonymous op-out was deployed. So in some way it's probably specific to your setup. I'm afraid the only way we can figure it out is to ask you to do some testing.

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.

In T85923#958482, @Tgr wrote:

I don't use Safari myself but googling it says that you can open the console with Option+Cmd+C. After that just copy/paste encodeURIComponent(JSON.stringify(localStorage)).length in the window that opened and press enter.

According to what I have done the number is "2600025."

Not sure about efficient, but the most effective way is always using the bug tracker; and you are the first person who reported this in the 6 months since anonymous op-out was deployed. So in some way it's probably specific to your setup. I'm afraid the only way we can figure it out is to ask you to do some testing.

I only used the bug tracker because I was frustrated. The average user would have given up since there's no easily accessible feedback form available to report bugs. They had to make an account on Wikipedia and then find where the bug tracker is to lodge my complaint. Because I was frustrated and stubborn I did it. There are probably dozens if not hundreds of people with this issue, but only I bothered to report it. I don't see why I should have to in the first place, since like I said, there should be a feedback form for people to report issues.

Also... I reported the bug,.. my job is done. I'm not a developer. I am getting emails in my spam folder from this forum site.

I should mention that the problem still happens, it hasn't changed any at all. I have noticed however that it happens after I restart my computer, but not every time I do. If it is to happen it will happen the first time I access Wikipedia after a reboot.

What is the cookie that tells the server my choice not to use the Media Viewer? I will make sure it never gets deleted. That should put an end to this nonsense for good. I periodically purge cookies and caches and such.

In T85923#2428390, @Ikaruseijin wrote:

According to what I have done the number is "2600025."

Thanks! Can you also check what number this website gives (in the "Results will appear below" section)?

What is the cookie that tells the server my choice not to use the Media Viewer? I will make sure it never gets deleted. That should put an end to this nonsense for good. I periodically purge cookies and caches and such.

Disabling is done by setting wgMediaViewerOnClick to 0 in localStorage.

In T85923#2429254, @Tgr wrote:

In T85923#2428390, @Ikaruseijin wrote:

According to what I have done the number is "2600025."

Thanks! Can you also check what number this website gives (in the "Results will appear below" section)?

It says:

"2600000 characters were stored successfully, but 2700000 weren't"

What is the cookie that tells the server my choice not to use the Media Viewer? I will make sure it never gets deleted. That should put an end to this nonsense for good. I periodically purge cookies and caches and such.

Disabling is done by setting wgMediaViewerOnClick to 0 in localStorage.

Which means absolutely nothing to me.

I have put wikipedia, wikimedia, mediawiki, cookies on a list of cookies I keep no matter what, that's the best I can do.

That probably means that your local storage is full and MediaViewer is unable to store its preferences. In the past T66721 has caused similar issues.

The setting is not stored in a cookie (cookies are generally bad as they are sent to the server on every request and so create a performance and data usage overhead) so changing cookie settings will not help.

In T85923#2471298, @Tgr wrote:

That probably means that your local storage is full and MediaViewer is unable to store its preferences.

That sounds plausible, but unlikely given @Ikaruseijin observes the feature being disabled for several consecutive days.

And, as previously asserted, existing keys are never evicted (like a database). Once set and successfully retrieved even once, nothing can delete that setting unless explicitly done so by MediaViewer or by the user clearing all their cookies (which in most browsers also clears local storage).

@Ikaruseijin: Is this still an issue nowadays?