Just another random volunteer. I love offline, a lot.
- User Since
- Aug 15 2016, 5:06 AM (74 w, 3 d)
- IRC Nick
- LDAP User
- MediaWiki User
Does this task really want the users to know "which compilation they're using" ? I don't see any mention about it in the task description or in the comments.
I guess this think needs a re-triage as I've updated the task description considerably.
Is this task about getting random pages with the following developer settings ?
How is this different from T183901: Reword post edit notification to reflect save->publish change
That comment wasn't as useful as I thought it should be. Here's a better one.
Tue, Jan 16
Mon, Jan 15
Sun, Jan 14
There issue seems to be more deeper than I initially thought. I've updated the task description to document them.
Make promotion of the feature more contextually-relevant - e.g., promote the feature to users when they first go offline
Fri, Jan 12
I even get the "Because you read" card for the re-direct page. I'm not sure whether it's a consequence of this.
This seems to be having worser consequences that just that.
Tue, Jan 9
Sat, Jan 6
I experience the same issue. I stated this initially in the talk page of community tech page. The only way I could dismiss them is by going to Special:Notifications and marking them as read. I did try restarting Firefox with Add-ons disabled and the result was the same. I also tried clicking on the notification using Chromium and it had not effect too.
Fri, Jan 5
I guess the following comment in the previously linked Mozilla support post seems to the reason why it's not working for me though I'm not 100% sure about it.
Here's a screenshot for the issue noted above,
I'm sorry to say this but I think it's broken again on Firefox. Alt+Shift+S does nothing inside the "Save your changes" modal for me, not even focusing the "Publish changes" button. For more context see, https://www.mediawiki.org/wiki/Topic:U52m0fn4n52eoxvm
Thu, Jan 4
I experienced the same issue some time ago and reported this with a screen cast in the Feedback board of the Visual wikitext editor but it seemed to not to have got any attention. I saw this on Firefox Nightly 59.0a1 on a Debian GNU/Linux 9 (stretch).
Here's another instance of incorrect syntax highlight: *#*:#. The last # is not highlighted though it represents a list item.
Here's another instance that probably has to be changed,
Wed, Jan 3
Tue, Jan 2
Also occurs in the following environment,
Mon, Jan 1
Mon, Dec 25
It seems the ones in the task description have already been completed. I've added one other minor thing I noticed, now.
Re-opening just in case the comment wasn't noticed.
Thu, Dec 21
What I meant by this is are there cases where ( !(window.chrome === false) && browserVersion > 41 && chromeInUserAgent(userAgent) ) where the download button does not work?
@Jdlrobson Just for the sake of clarity, you meant !!window.chrome === false when you said window.chrome === false right ?
Wed, Dec 20
I observe the same behaviour as stated in this comment.
@phuedx I guess I could help you a little.
Display the download button if Android version is 5.0 or above and Chrome version is 40.0 or above.
Tue, Dec 19
Dec 18 2017
Dec 17 2017
Dec 16 2017
Dec 15 2017
Surprisingly, I recently witnessed a possibly related issue this time with a direct link to the page. There's a link to the Natural language processing article in this Signpost article. When I hovered over it I got the Looks like there isn't a preview for this page message. This time purging the page resulted in the preview being shown.
I tried to see what the behaviour was on friend's device which had a custom rom (modified firmware) installed. Surprisingly, the download icon did not work even on Chrome version 63.x !! I could guess that the custom firmware doesn't have the print capability like the original one (I couldn't see 'Print' even in the 'Share' menu). I'm not sure how this issue should be handled, but I'm pretty sure that it should be handled in some way. That's because, the user would not expect the "Download" feature to be dependant upon the "Print" functionality of his device.
Should we be mentioning about the issue that, download button in the older versions of chrome and browsers based on that might not work, in the upcoming Tech News? I guess it might be useful. The planned publication deadline for the upcoming edition seems to be Monday 18 December 2017.
Dec 13 2017
The behaviour seems to have changed a little. Now I observe the following behaviour in the same device,
As an aside, the color of the toggle button seems to be too much similar to that of the background so that it's a little difficult to distinguish it from the background. Is this intentional? If yes, what might be the reason?
I saw this occur twice (out of three attempts) for the following steps:
Dec 12 2017
I guess there's still an issue around this one. I recently noticed that for the Hamster Wheel article the About the article shows it's available in 9 other languages while I see 10 items in the Other languages view. The list seems to contain 8 items for other languages and 2 items for chinese which seem to be pointing to the same article (!). You could confirm that by choosing View in browser options for both chinese variants to see that they open the same webpage. As I'm not a chinese person, I'm not sure what should differ for both chinese variants.
Dec 10 2017
Are there any browsers after Chrome version >= 37 for which the print button works/doesn't work?
Dec 8 2017
What is the list of browser that are displaying the download button that are not Chrome?
Dec 6 2017
Caught a similar one, T182207. This time it's an older version of Google Chrome on a different device.