I've seen the same thing, but could not reproduce. Same setup, but I was probably using Firefox as that is my usual browser unless I must check something in an alternate browser.
Wed, Jan 17
Switched to a bot account and then it works…
Tried an incognito window in Chromium, same thing happen there.
Also tested Norwegian Bokmål and English, and same thing still happen.
Interesting, I still got the problem in Firefox 57.0.4
Now I get hits on "Ekaas", so I guess as @jhsoby that this is a fluke – or (scary) Heisenbug…
Could you provide each steps to reproduce? I've just checked by searching, and I got hits on "Jünge" but not "Ekaas".
First example seems to work when I'm logged in, second fails.
Tue, Jan 16
Unwind from the innermost element that the cursor is inside, to the outermost, for each remove style. In this case
the i-tag will newer be removed, as the cursor is not inside the element.
Yeah, I believe this is about a user clicking on a word, then trying to remove the styling without further selection. Because nothing happen the user assumes the action is broken. If nothing is selected, then the word or styled phrase (emphasized text, etc) should be selected before the styling is subsequently removed.
Sun, Jan 7
Dec 6 2017
Dec 3 2017
Dec 2 2017
Nov 26 2017
Nov 20 2017
Nov 9 2017
Ok, I can ask them to create such an entry.
Nov 4 2017
I'll start a discussion at nowiki if this is in fact an acceptable solution. (w:no:Wikipedia:Torget#Oppdatering av gamle rå referanser)
Perhaps someone working on VisualEditor/Citoid could say if this is possible?
I try to figure out what is needed to replace the old references that uses raw wikitext with the new form that uses the template editor. It is not a bug, it is a feature request!
Oct 30 2017
Oct 27 2017
The thread has been archived, I've updated the link (w:no:Wikipedia:Torget#Recent unpatrolled). The users comment is
There is a gadget "Språkrekkefølge: Sorter lenker til andre språk akkurat slik du ønsker det. Se bruksanvisning." that might interfere with languages. It is the last one in the section "Innhold". Code at w:no:MediaWiki:Gadget-InterwikiOrder.js The user that has the problem has disabled all gadgets, so I doubt this is the root cause.
Oct 24 2017
Oct 22 2017
There has been a new, and quite confusing vote at nowiki. It can be found at Ny avstemming om nb.wikipedia.org (New voting about nb.wikipedia.org) and the outcome at Avstemning (nb/no) (Voting (nb/no)) with an actual outcome of 23 for the change and 9 against. Three users have publicly abstained from casting a vote.
Oct 21 2017
Not sure which navigation popup this is, but it was not noticed by any one involved in the thread at Torget.
I can not reproduce this in versjon 61.0.3163.100 (Offisiell delversjon) Built on Ubuntu , running on Ubuntu 17.04 (64-bit)
OS: Windows 10 Home, Chrome: 62.0.3202.62. The user has tried several browser versions.
Oct 20 2017
I can ask for specific browser versions, but the user avilena says "I have tried with the latest version of Chrome and Firefox, 64-bit." ("Jeg har prøvd med siste versjon av Chrome og Firefox, 64-bit.")
Oct 16 2017
A stack trace from the user
As I could not identify any problems with the gadgets (sure there are problem with them) I suspect there are something interfering from other user settings. Trying to add and remove each of them will take a lot of time.
Oct 14 2017
Oct 13 2017
Oct 12 2017
Thank you @Jdforrester-WMF!
Oct 11 2017
Sep 29 2017
Sep 27 2017
Sep 25 2017
I wonder if this is at least two very different things, the reference system in use for a ref mark and whether it is inlined.
Sep 24 2017
Sep 21 2017
Closing this as it will imply to break with BCP-47. Choosing "invalid" as per T173602#3613072
Sep 18 2017
Slightly off-topic but the nowiki community would probably accept a move if old URLs will work for some time. I also believe that the community at both nowiki and nnwiki will accept an intercept of page requests for th no-domain a few years into the future, with a manual rerouting of the request to a nn- or nb-domain. The only thing they probably won't accept is broken URLs.
Sep 17 2017
The action it proposes goes against use of public standards, so even if it is possible to do the proposed action it should not be done. I would say it is a clear "decline", but other may have other opinions.
Sorry, but Riksmål is an unofficial deviation from the established standard for Bokmål. You should instead use time to try to identify the actual articles that is written in correct Riksmål at nowiki. Note that Riksmål does not even have a valid language code.
Sep 16 2017
There are 44 articles at nnwiki in Høgnorsk (w:nn:Kategori:Høgnorskartiklar. Those articles are in a very archaic language, even for Nynorsk. I have tried to figure out how many articles there are at nowiki in Riksmål, and the more stringent checks indicate a two-digit number. If I ease the checks I get a three-digit number, and with extremly weak tests four-digits.
Sep 15 2017
As a note to T151301#3291681; the attribute "name" has usually no implication on uniqueness, but "id" has. To assume it is unique within a "group" seems consistent to me. If "name" shall be forced to be unique, then it would be better to change it to "id".
It is a really bad idea to translate tag functions. Actually I believe it is a really bad idea to translate all such markup and programming constructs without a working translator for those constructs.
Sep 14 2017
On T171581#3531014, I believe it is a really bad idea to translate tag functions. Actually I believe it is a really bad idea to translate all such markup and programming constructs without a working translator for those constructs.
The usual wording for an attribute that make an element depend on something else is "for". The attribute "for" would then hold the id of the other element. Because the name is used as the id, if no explicit id exists, then "for" would hold the name. The group must also be specified as the name is only unique within a group. No explicit group attribute imply using a default group.
Sep 13 2017
Sep 1 2017
@Niharika Could it be lazy-fixed after the highlighter has loaded? The user expect it to be there, but he would probably not discover if it were gone for a short while.
I'm on a fairly fast connection, but it has a noticeable latency. It could be the reason why see this bug. It is quite annoying as I must check all the time if the cursor is positioned where I expect it to be.
Aug 30 2017
Aug 26 2017
Seems like this is fixed? Nice! :)
Very nice extension though!
It is something I observed when I logged in with a new account, then it seems like I got logged out each time I tried to save, then got a warning before I could save, but then was returned to a logged in page, and then looped around again. Not sure what caused it, but a hard reload seems to fix it. I have not seen this in production, and because a hard reload fixed it, I would guess some libs and/or cookie are out of sync. (Testing on simplewiki at wmflabs it seems like something is gong on, I'm being logged out and back in.)
Seems like it is working, testpage. Any idea why only some editors observed the problem? I assumed the array was out of bounds, forgot to mention that.
Aug 25 2017
The patch seems a likely fix, but still won't explain why it happens to only some users.
Did a "restore to default settings" and still got the bug.
Changed to "English", still got the bug.
This is a page in the main space on nowiki.
Both my account "jeblad" and "jeblad (bot)" shows the bug.
No bug while writing in your sandbox! That is weird!
There are also another bug, the "try me" dialog box won't go away unless I click the "X".
In Chromium the content in the edit frame disappears when I turn on syntax highlight. Another bug, T174123, and it blocks me from testing this bug.