User talk:Cacycle/wikEd/Archive 011

It appears that wikEd sometimes inserts or deletes a newline in the edit window. Typical scenario is as follows:

1. you copy and paste something in the edit window
2. you see that there is e.g. one empty line in the edit window
3. after you save the changes and edit the article again, you find out that there are two empty lines (or no empty lines) where there used to be one

This happens in Google Chrome, never in Firefox. Do you know what might be the reason? I'm suspecting a Webkit bug... GregorB (talk) 22:38, 18 January 2009 (UTC)

:Funny, it happened without a copy/paste, just as I was writing this. See the diff to the previous edit. GregorB (talk) 22:40, 18 January 2009 (UTC)

:: When pasting rich text it is not always easy to see the number of line breaks. Push the Image:WikEd_wikify.png or Image:WikEd_textify.png button to remove the original formatting of your pasted text. I could not reproduce your problem in Chrome, please provide a detailed how-to so that I can reproduce it. Thanks, Cacycle (talk) 00:26, 19 January 2009 (UTC)

:::Here's what "works" for me:

:::#Open e.g. [http://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd&action=edit§ion=new this] page in a new tab.

:::#Type ###

:::#Click on "Preview" (or on Image:WikEd_textify.png).

:::#"#" characters from the step 2 are now separated by empty lines

:::The same happened with the numbered list items from my edit as I was writing it. :) GregorB (talk) 17:01, 19 January 2009 (UTC)

::::Confirmed -- this also reproduces the bug on Safari. Viktor Haag (talk) 13:29, 22 January 2009 (UTC)

:: I also echo the suspicion that this may be a WebKit issue: this behaviour also happens to me when using wikEd on Safari (Safari 3.2.1/5525.27.1 running on Mac OSX 10.5.6 on a Dual2 PPC G5). This is not limited to pasting rich text for me. This happens to me during the normal course of editing a page, and usually seems to be clustered around lines with headings and/or templates in them. Unfortunately, it doesn't seem to me to be entirely reproducible or predictable. Viktor Haag (talk) 13:54, 19 January 2009 (UTC)

::: Maybe it is a Mac-only problem. GregorB: please could you fill out the bug report form on the top for your system information. Thanks, Cacycle (talk) 14:46, 22 January 2009 (UTC)

::::Here it is:

::::*WikEd version: 0.9.68a

::::*Browser id: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.43 Safari/525.19

::::*Console errors: none (hope I'm getting it right: ctrl-shift-J window)

::::*Add-ons: none

::::*User scripts: none

::::*OS: Windows XP SP3

::::*Problem and steps to reproduce: as described above

::::Apparently not Mac-related... GregorB (talk) 15:29, 22 January 2009 (UTC)

::::: Thanks, I can now reproduce this and will try to fix this as soon as I find the time. Cacycle (talk) 02:55, 26 January 2009 (UTC)

:::::: Safari and Chrome use

:::::::Divs are inserted indeed; this behavior can be seen at e.g. http://www.kevinroth.com/rte/demo.htm. I could not find this reported at http://code.google.com/p/chromium/issues/list - which is a bit odd, since one would expect this to hurt other rich text editors too. It's probably a some sort of WebKit misfeature. I'm currently doing 25% of editing in Chrome, 75% in Firefox. This could force me back to 100% Firefox - no big deal perhaps, but still... GregorB (talk) 09:36, 27 January 2009 (UTC)

:::::::: I have probably fixed this with browser detection in 0.9.71. Please report back if you still experience problems related to this. Thanks, Cacycle (talk) 03:15, 2 February 2009 (UTC)

:::::::::Just found this thread. This is still happening to me (Feb 4, Chrome/WinXP). First it deletes the breaks[http://en.wikipedia.org/w/index.php?title=Stormwater&diff=prev&oldid=268578774], then inserts too many.[http://en.wikipedia.org/w/index.php?title=Stormwater&diff=prev&oldid=268578947] I've turned off wikEd and it works fine. Incidentally, in Chrome misspelled words are only highlighted when wikEd is turned off... don't know if you aware of this or not. NJGW (talk) 07:08, 5 February 2009 (UTC)

:::::::::: It works fine for me with Chrome >= 1.0.154.43 / WinXP. Please could you fill out the full bug report form on top of the page so that I can reproduce your problems. Missing spellcheck is a browser problem not related to wikEd. Thanks in advance, Cacycle (talk) 04:53, 19 February 2009 (UTC)

::::::::::: Unfortunately, the problem persists for me in 0.9.73a (i.e. I can still reproduce it from steps given above). My version of Google Chrome is now 1.0.154.48, and the rest is the same (Win XP SP3, etc.). GregorB (talk) 09:07, 19 February 2009 (UTC)

::::::::::: I still have the problem here as well. Using Safari 4 5528.16, with default user agent (which I assume is Safari Public Beta - Mac), with 0.9.76b (built Mar 29/09). If I insert a new line in front of a paragraph (on the same line just before its first character), the newline seems to stick around. If I try to insert a newline by adding it to the end of the preceeding paragraph, it appears to get deleted. Viktor Haag (talk) 15:54, 30 March 2009 (UTC)

::::::::::: The problem still seems to exist with same version of Safari as my last report, and with 0.9.78G (build April 26/2009). Viktor Haag (talk) 16:31, 28 April 2009 (UTC)

Please be as specific as possible so that I can reproduce your problem - what do you mean by "sticking around" and when does it "appear to get deleted"? Do you also experience the Safari bug that turns the text blue after pushing the [T] button? Cacycle (talk) 20:53, 28 April 2009 (UTC)

:The first thing I tried in the new Google Chrome (2.0.172.28) was the four-step process to reproduce the problem described above. WikEd is 0.9.78 at the moment. Unfortunately, the behavior is the same... GregorB (talk) 09:52, 22 May 2009 (UTC)

:I too have tried 0.9.79c with the four-step process above with Safari (v4 Public Beta on Mac), and the behaviour is still the same, as with Google Chrome. Here is a process to describe the problem I'm seeing on Safari in addition to the test listed above:

:::# Open e.g. [http://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd&action=edit§ion=new this]page in a new tab.

:::# Type "== This is a heading ==" on the top line of the text box (line one).

:::# Type "This is some plain text following the heading." on the very next line (line two).

:::# Click "Preview" : the text in the editing window changes so that there's a newline inserted above the heading text and between the heading text and the line of plain text.

:This is what I mean by "spurious newlines". Viktor Haag (talk) 14:20, 27 May 2009 (UTC)

::With WikEd 0.9.80 G, running on Safari Version 4.0 (5530.17), this behaviour is partially fixed; from the immediately preceding example, now there's a newline inserted between the heading text and the line of plain text, but no extra line inserted above the heading text. Viktor Haag (talk) 19:32, 15 June 2009 (UTC)

:::Ditto for Chrome 2.0.172.33 (Win XP), wikEd 0.9.83a. Unfortunately this is still enough for me to refrain from using Chrome. GregorB (talk) 09:22, 29 June 2009 (UTC)

::With WikEd 0.9.85d G, running on Safari Version 4.0.2 (5530.19), the immediately preceding test still inserts a spurious newline between the heading text and the line of plain text. I have noticed anecdotally that, when creating table markup, WikEd inserts newlines between "rows" of table text as well. This bug is not a critical fault, but it is a major pain for usability.Viktor Haag (talk) 14:59, 6 August 2009 (UTC)

::: I am currently working on a new highlighting engine, let's see if it persists after the move. If not, I will try to fix it then, promised. Cacycle (talk) 17:23, 6 August 2009 (UTC)

:::: This is good news; it would be useful to know when the target date for this new engine is; I'm using WikEd 0.9.88b G with Safari Version 4.0.3 (5531.9), and the problems described above in this thread are still present. Viktor Haag (talk) 13:55, 1 October 2009 (UTC)

::: I'm now using 0.9.90f G with Safari 4.0.4 and the example above still has problems. Viktor Haag (talk) 14:37, 17 February 2010 (UTC)

:I came here to report that an other user and I have this problem too at the hungarian wikipedia. We use Chrome, personally I use the 6.0.427.0 beta, I really love wikEd, I didn't want to turn it but this bug is very annoying... I hope you the fix come soon (either from chromium dev's or wikEd's). ~ Boro (talk) 18:29, 10 August 2010 (UTC)

:: Please could you file a bug report (see top of this page) with wikEd and Chrome versions at the bottom of this page and a link to this section? Thanks, Cacycle (talk) 21:59, 10 August 2010 (UTC)

Please see below, should be fixed in 0.9.91k. Cacycle (talk) 21:10, 16 August 2010 (UTC)== Inserting/deleting newlines spuriously ==

It appears that wikEd sometimes inserts or deletes a newline in the edit window. Typical scenario is as follows:

1. you copy and paste something in the edit window
2. you see that there is e.g. one empty line in the edit window
3. after you save the changes and edit the article again, you find out that there are two empty lines (or no empty lines) where there used to be one

This happens in Google Chrome, never in Firefox. Do you know what might be the reason? I'm suspecting a Webkit bug... GregorB (talk) 22:38, 18 January 2009 (UTC)

:Funny, it happened without a copy/paste, just as I was writing this. See the diff to the previous edit. GregorB (talk) 22:40, 18 January 2009 (UTC)

:: When pasting rich text it is not always easy to see the number of line breaks. Push the Image:WikEd_wikify.png or Image:WikEd_textify.png button to remove the original formatting of your pasted text. I could not reproduce your problem in Chrome, please provide a detailed how-to so that I can reproduce it. Thanks, Cacycle (talk) 00:26, 19 January 2009 (UTC)

:::Here's what "works" for me:

:::#Open e.g. [http://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd&action=edit§ion=new this] page in a new tab.

:::#Type ###

:::#Click on "Preview" (or on Image:WikEd_textify.png).

:::#"#" characters from the step 2 are now separated by empty lines

:::The same happened with the numbered list items from my edit as I was writing it. :) GregorB (talk) 17:01, 19 January 2009 (UTC)

::::Confirmed -- this also reproduces the bug on Safari. Viktor Haag (talk) 13:29, 22 January 2009 (UTC)

:: I also echo the suspicion that this may be a WebKit issue: this behaviour also happens to me when using wikEd on Safari (Safari 3.2.1/5525.27.1 running on Mac OSX 10.5.6 on a Dual2 PPC G5). This is not limited to pasting rich text for me. This happens to me during the normal course of editing a page, and usually seems to be clustered around lines with headings and/or templates in them. Unfortunately, it doesn't seem to me to be entirely reproducible or predictable. Viktor Haag (talk) 13:54, 19 January 2009 (UTC)

::: Maybe it is a Mac-only problem. GregorB: please could you fill out the bug report form on the top for your system information. Thanks, Cacycle (talk) 14:46, 22 January 2009 (UTC)

::::Here it is:

::::*WikEd version: 0.9.68a

::::*Browser id: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.43 Safari/525.19

::::*Console errors: none (hope I'm getting it right: ctrl-shift-J window)

::::*Add-ons: none

::::*User scripts: none

::::*OS: Windows XP SP3

::::*Problem and steps to reproduce: as described above

::::Apparently not Mac-related... GregorB (talk) 15:29, 22 January 2009 (UTC)

::::: Thanks, I can now reproduce this and will try to fix this as soon as I find the time. Cacycle (talk) 02:55, 26 January 2009 (UTC)

:::::: Safari and Chrome use

:::::::Divs are inserted indeed; this behavior can be seen at e.g. http://www.kevinroth.com/rte/demo.htm. I could not find this reported at http://code.google.com/p/chromium/issues/list - which is a bit odd, since one would expect this to hurt other rich text editors too. It's probably a some sort of WebKit misfeature. I'm currently doing 25% of editing in Chrome, 75% in Firefox. This could force me back to 100% Firefox - no big deal perhaps, but still... GregorB (talk) 09:36, 27 January 2009 (UTC)

:::::::: I have probably fixed this with browser detection in 0.9.71. Please report back if you still experience problems related to this. Thanks, Cacycle (talk) 03:15, 2 February 2009 (UTC)

:::::::::Just found this thread. This is still happening to me (Feb 4, Chrome/WinXP). First it deletes the breaks[http://en.wikipedia.org/w/index.php?title=Stormwater&diff=prev&oldid=268578774], then inserts too many.[http://en.wikipedia.org/w/index.php?title=Stormwater&diff=prev&oldid=268578947] I've turned off wikEd and it works fine. Incidentally, in Chrome misspelled words are only highlighted when wikEd is turned off... don't know if you aware of this or not. NJGW (talk) 07:08, 5 February 2009 (UTC)

:::::::::: It works fine for me with Chrome >= 1.0.154.43 / WinXP. Please could you fill out the full bug report form on top of the page so that I can reproduce your problems. Missing spellcheck is a browser problem not related to wikEd. Thanks in advance, Cacycle (talk) 04:53, 19 February 2009 (UTC)

::::::::::: Unfortunately, the problem persists for me in 0.9.73a (i.e. I can still reproduce it from steps given above). My version of Google Chrome is now 1.0.154.48, and the rest is the same (Win XP SP3, etc.). GregorB (talk) 09:07, 19 February 2009 (UTC)

::::::::::: I still have the problem here as well. Using Safari 4 5528.16, with default user agent (which I assume is Safari Public Beta - Mac), with 0.9.76b (built Mar 29/09). If I insert a new line in front of a paragraph (on the same line just before its first character), the newline seems to stick around. If I try to insert a newline by adding it to the end of the preceeding paragraph, it appears to get deleted. Viktor Haag (talk) 15:54, 30 March 2009 (UTC)

::::::::::: The problem still seems to exist with same version of Safari as my last report, and with 0.9.78G (build April 26/2009). Viktor Haag (talk) 16:31, 28 April 2009 (UTC)

Please be as specific as possible so that I can reproduce your problem - what do you mean by "sticking around" and when does it "appear to get deleted"? Do you also experience the Safari bug that turns the text blue after pushing the [T] button? Cacycle (talk) 20:53, 28 April 2009 (UTC)

:The first thing I tried in the new Google Chrome (2.0.172.28) was the four-step process to reproduce the problem described above. WikEd is 0.9.78 at the moment. Unfortunately, the behavior is the same... GregorB (talk) 09:52, 22 May 2009 (UTC)

:I too have tried 0.9.79c with the four-step process above with Safari (v4 Public Beta on Mac), and the behaviour is still the same, as with Google Chrome. Here is a process to describe the problem I'm seeing on Safari in addition to the test listed above:

:::# Open e.g. [http://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd&action=edit§ion=new this]page in a new tab.

:::# Type "== This is a heading ==" on the top line of the text box (line one).

:::# Type "This is some plain text following the heading." on the very next line (line two).

:::# Click "Preview" : the text in the editing window changes so that there's a newline inserted above the heading text and between the heading text and the line of plain text.

:This is what I mean by "spurious newlines". Viktor Haag (talk) 14:20, 27 May 2009 (UTC)

::With WikEd 0.9.80 G, running on Safari Version 4.0 (5530.17), this behaviour is partially fixed; from the immediately preceding example, now there's a newline inserted between the heading text and the line of plain text, but no extra line inserted above the heading text. Viktor Haag (talk) 19:32, 15 June 2009 (UTC)

:::Ditto for Chrome 2.0.172.33 (Win XP), wikEd 0.9.83a. Unfortunately this is still enough for me to refrain from using Chrome. GregorB (talk) 09:22, 29 June 2009 (UTC)

::With WikEd 0.9.85d G, running on Safari Version 4.0.2 (5530.19), the immediately preceding test still inserts a spurious newline between the heading text and the line of plain text. I have noticed anecdotally that, when creating table markup, WikEd inserts newlines between "rows" of table text as well. This bug is not a critical fault, but it is a major pain for usability.Viktor Haag (talk) 14:59, 6 August 2009 (UTC)

::: I am currently working on a new highlighting engine, let's see if it persists after the move. If not, I will try to fix it then, promised. Cacycle (talk) 17:23, 6 August 2009 (UTC)

:::: This is good news; it would be useful to know when the target date for this new engine is; I'm using WikEd 0.9.88b G with Safari Version 4.0.3 (5531.9), and the problems described above in this thread are still present. Viktor Haag (talk) 13:55, 1 October 2009 (UTC)

::: I'm now using 0.9.90f G with Safari 4.0.4 and the example above still has problems. Viktor Haag (talk) 14:37, 17 February 2010 (UTC)

:I came here to report that an other user and I have this problem too at the hungarian wikipedia. We use Chrome, personally I use the 6.0.427.0 beta, I really love wikEd, I didn't want to turn it but this bug is very annoying... I hope you the fix come soon (either from chromium dev's or wikEd's). ~ Boro (talk) 18:29, 10 August 2010 (UTC)

:: Please could you file a bug report (see top of this page) with wikEd and Chrome versions at the bottom of this page and a link to this section? Thanks, Cacycle (talk) 21:59, 10 August 2010 (UTC)

Please see below, should be fixed in 0.9.91k. Cacycle (talk) 21:10, 16 August 2010 (UTC)

Incremental find does not work right in Google Chrome (wikEd 0.9.75, Chrome 1.0.154.48). Here's how to reproduce:

1. Go to e.g. [http://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd&action=edit this page]
2. In the wikEd search box, type letter by letter: wiked
3. Notice that with each keypress the focus jumps to the next word matching the entered string, instead of staying on the same word. So, typing "wiked" gets you to the fifth instance of the word in the edit window, instead of the first.

This works as expected in Firefox 3. GregorB (talk) 14:13, 11 March 2009 (UTC)

:: Thanks for reporting, I will check into this (might be a tricky one...) 23:36, 12 March 2009 (UTC)

::: Works in wikEd 0.9.91o. Cacycle (talk) 19:24, 24 August 2010 (UTC)

When I use the single check button, it removes the space following the pipe in a Category link on an article that is supposed to be at the top of its category (e.g., " " --> ""). It took me a while to realize this as the diff before saving is nearly identical, but if the space isn't reinserted before saving, the link is saved as with the page title inserted after the pipe. This screws up the sorting in the category and it would be helpful if you could get the script to skip fixing spaces following a pipe in category links. I realize it must be wikimedia software adding the pagename after the pipe when saving—causing the discrepancy between diffs before and after saving—but tweaking the script would prevent accidental changes to the sorting. Thanks. —Ost (talk) 18:39, 14 July 2009 (UTC)

:Would you happen to know more about the reason for this behavior? It's really annoying to repair similar miscategorizations at a later stage. Thanks. -- —Preceding unsigned comment added by 217.227.116.77 (talk) 08:09, 5 June 2010 (UTC)

:: Fixed in 0.9.91i. Cacycle (talk) 20:44, 22 July 2010 (UTC)

I've been using Firefox 3.6 for a while, and I've had a problem with the search function. When I type a letter in the search box, my cursor jumps to the first occurrence of that letter. When I click again in the search box and type a second letter, the cursor jumps to the first occurrence of that two-letter combination; and so on.

I don't see this behavior in Firefox 3.5.7, but I'm not 100% positive every extension and setting is the same between the two installations. Any ideas? — Malik Shabazz ^Talk/_Stalk 17:44, 20 January 2010 (UTC)

: I will check into this next week :-) Thanks for reporting, Cacycle (talk) 18:50, 20 January 2010 (UTC)

::Thanks. — Malik Shabazz ^Talk/_Stalk 18:52, 20 January 2010 (UTC)

:Same here (Firefox 3.6, Windows XP). Also, initially there is no cursor in the edit box. It appears only when you go to the search box, then return to the edit box. GregorB (talk) 21:43, 21 January 2010 (UTC)

:On a more positive note, this appears to be fixed in 3.6. GregorB (talk) 22:12, 21 January 2010 (UTC)

:: I can confirm both bugs on FF 3.6 (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6) (Leopard 10.5.8). Search & replace are useless this way, unless a user types data into the main edit box and/or drag-selects, then drags/drops into the search/replace fields where appropriate. Very cumbersome workaround, for fast typists anyway.
---Schweiwikist (talk) 07:15, 23 January 2010 (UTC)
Followup: Bugs gone under: (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5)
---Schweiwikist (talk) 07:23, 23 January 2010 (UTC)

:::Editbox cursor bug still present under Windows Vista and 7. Can be corrected on an edit-by-edit basis by turning off WikiEd (top right of the page) and turning it back on. --King Öomie 15:10, 25 January 2010 (UTC)

:::: Fixed with a workaround in 0.9.90c and filed the Mozilla bug report [https://bugzilla.mozilla.org/show_bug.cgi?id=543204 543204]. Cacycle (talk) 13:55, 30 January 2010 (UTC)

wikEd has always done some weird doubling of return characters when typing a return character or pasting something in the page, but I just turn of wikEd for a second paste it in and turned it back on, no problem. But recently, don't know exactly when, wikEd started to ad two return characters at the top of the page, this is extremely annoying as the only way to get rid of them, since they don't show initially, is to do a full preview (not inline) which then reveals them, so I can see them, if I just delete them them there, they're not gone. Removing them, deactivating wikEd, and reactivating it just makes them pop up again. The only way is to remove them, preview the page again and then it's only one, and then I can remove that one too. Editing a page and saving it in one turn is out of the question at this point. This is, as you can imagine, extremely annoying as it adds a blank space at the top of the page. I use Mac OS X 10.6, Safari 4.0.4 (6531.32.10), no changes on my end as far as I can remember. _Xeworlebi ^(t•c) 14:09, 25 January 2010 (UTC)

:This is a known problem with Webkit-based browsers (Safari and Chrome). See this. GregorB (talk) 17:02, 25 January 2010 (UTC)

::Didn't see that, apologies. Looking trough it it seems a pretty old problem, I never had that much of a problem with it, but recently with the hidden double return at the top of the page it is getting to the point that I have wikEd turned off more than on, which is a shame. _Xeworlebi ^(t•c) 00:58, 26 January 2010 (UTC)

:::This drives me away from using Google Chrome. Still, Firefox is fine, so it's not that bad in my case. GregorB (talk) 14:38, 27 January 2010 (UTC)

:::: It is a Webkit (Safari, Chrome) bug, I have filed the Webkit bug report [https://bugs.webkit.org/show_bug.cgi?id=34377 34377]. Cacycle (talk) 19:26, 30 January 2010 (UTC)

Before I get to that bug, WikiEd refuses to load when I click on the New Section tab on the discussion page. So I will create this section and then edit it. ("Loading error - wikiEd 0.9.90a G (January 15, 2010) Click to disable" in browser Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12)

Hgrosser (talk) 23:49, 26 January 2010 (UTC)

When the ... construct is used, wikiEd does not show the syntax coloring in its preview unless Wikipedia’s built-in Preview function is used to preview the page first (and this preview contains a block in the same language as the wikiEd preview). Here’s a sample (from Rm (Unix)#User-Proofing):

if [ -n "$PS1" ] ; then

rm ()

{

ls -FCsd "$@"

echo 'remove[ny]? ' | tr -d '\012' ; read

if [ "_$REPLY" = "_y" ]; then

/bin/rm -rf "$@"

else

echo '(cancelled)'

fi

}

fi

Hgrosser (talk) 00:11, 27 January 2010 (UTC)

: I have added GeSHi support for local previews in 0.9.90d. The new section issue has already been fixed in a previous release. Thanks for the suggestion, Cacycle (talk) 22:08, 30 January 2010 (UTC)

When I use WikEd on my laptop it turning off the cursor. Anything one can do about this as I prefer the cursor on? Doc James (talk · contribs · email) 14:23, 27 January 2010 (UTC)

: That seems to be a Firefox 3.6. bug. The cursor appears after pushing wikEd buttons, e.g. Image:WikEd_textify.png. Cacycle (talk) 23:46, 27 January 2010 (UTC)

:: I have filed Firefox bug report [https://bugzilla.mozilla.org/show_bug.cgi?id=542727 542727]. Cacycle (talk) 08:48, 28 January 2010 (UTC)

:::Thanks hopefully they will fix it soon. Makes it a little hard to edit.Doc James (talk · contribs · email) 08:51, 28 January 2010 (UTC)

:::: Fixed with a workaround in 0.9.90c and filed the Mozilla bug report [https://bugzilla.mozilla.org/show_bug.cgi?id=542727 542727]. Cacycle (talk) 13:53, 30 January 2010 (UTC)

::::: Awesome job, thanks for the fix. Glycerine102 (talk) 18:39, 31 January 2010 (UTC)

:::::: The workaround does not work all the time :-( Cacycle (talk) 23:36, 31 January 2010 (UTC)

I am using WikEd with Safari and I have a problem with the edit summary field. When I go to edit a page the editor comes up with WikEd, however, this particular field is off the screen to the far left requiring me to scroll over to type a summary and then scroll back to the right to click save. What can I do? Supertouch (talk) 14:35, 27 January 2010 (UTC)

: I do not see this with wikEd 0.9.90b as a Gadget and Safari 4.0.4. Please could you fill out the bug form (top of this page)? Thanks, Cacycle (talk) 23:52, 27 January 2010 (UTC)

(wikEd version: 0.9.90b G; browser id: Mozilla/5.0 (Windows; U; Windows NT 5.1; el; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7)

Although they work just fine when previewing or saving a page, italics within links do not show properly within the edit window. For example, writing Italics (film) ought to show as Italics (film), but instead shows as Italics (film). It is a rather odd reversal.

Note: although the above text is admittedly rather more complicated than regular syntax, it also displays erroneously: it interprets the (real) closing apostrophes for the second example link's Italics as opening apostrophes for the rest of my message. It seems to be the same problem: a confusion between opening and closing apostrophes. Waltham, The Duke of 18:47, 29 January 2010 (UTC)

: The upcoming release of wikEd has a new highlighter that should be able to handle this. Thanks for reporting, Cacycle (talk) 21:11, 29 January 2010 (UTC)

:: Yes, the new wikEd^beta3 handles that correctly, see the top of the page for how to test that version :-) Cacycle (talk) 23:35, 31 January 2010 (UTC)

I tried the wikEd beta. My wikEd options don't work with it, apparently. Here they are if you want to take a look. They do indeed work with the current wikEd, though. Also, regarding wikEd beta, the buttons that appear to represent hidden templates and references on a Mac in Firefox have text that is a bit too small to read. It looks like they are using {{bcode|1=}}, as they look just like how buttons are formatted in Firefox on a Mac. Gary King (talk) 22:47, 31 January 2010 (UTC)

: The new wikEd version has a completely new highlighting system, therefore several of the old css styles do no longer work. The buttons are no real input elements, they are actually no real html elements, they are completely realized in css :-) Maybe they are too small to read because of your custom setting? BTW, I have just published beta3, please update with Shift-Reload. Cacycle (talk) 23:31, 31 January 2010 (UTC)

:: No, the buttons aren't affected by my custom settings because as I said, my custom settings don't even work anyway. Gary King (talk) 19:36, 1 February 2010 (UTC)

Usability Initiative beta uses a new skin called vector. User scripts for that skin are on User:Gary King/vector.js, not on User:Gary King/monobook.js. Cacycle (talk) 08:45, 15 February 2010 (UTC)

I've got the latest version of Firefox, not using any odd skins, Core 2 Duo laptop. When I pull up this month's diff (with WikEd diff enabled, WikEd otherwise disabled) of WP:MOS ("220 intermediate revisions not shown"), I get "Firefox not responding". It looks like the system responds again after 3 to 4 minutes, and the diff appears to be correct. Thought you'd want to know; I don't know whether there's something odd about this month's WP:MOS diff (this has never happened before, and I've used WikEd's diff button a lot) or whether something has changed in WikEd. - Dank (push to talk) 00:25, 1 February 2010 (UTC)

:P.S. If it matters, I don't have a slow machine: 4 Gigs of RAM, Windows 7, Dell. - Dank (push to talk) 01:18, 1 February 2010 (UTC)

:: Please could you provide the diff link for two specified revisions from the history page where it takes so long (e.g. http://en.wikipedia.org/w/index.php?title=Wikipedia%3AManual_of_Style&action=historysubmit&diff=341159534&oldid=334949000). BTW, with that link I do not see the problem. It could be a server / connection problem as wikEdDiff has to load both revisions from the server in the background in order to create the diff. Cacycle (talk) 08:21, 1 February 2010 (UTC)

:::http://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style&limit=250&action=history, click on 11:26 Dec 31, click on any version around the end of January (I tried several), push the button. - Dank (push to talk) 13:23, 1 February 2010 (UTC)

::::Out of curiosity, I tried [http://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style&diff=341159534&oldid=335090526 this]. Takes c. 15-20 seconds or so on my 2006 laptop. GregorB (talk) 15:29, 1 February 2010 (UTC)

:::: That would be this link: http://en.wikipedia.org/w/index.php?title=Wikipedia%3AManual_of_Style&action=historysubmit&diff=341159534&oldid=335090526 which takes less than 2 s for me (including the backgrount article text loading). Looks like a server/connection problem on your side to me... Cacycle (talk) 23:22, 1 February 2010 (UTC)

wikEd 0.9.90d (January 30, 2010) - on Firefox 3.6 and Google Chrome 5.0.307.1. No adding a script or switching on and off works... – Kochas (talk) 03:14, 5 February 2010 (UTC)

:I get the same error, both with Firefox 3.0.15 [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.15) Gecko/2009101601 Firefox/3.0.15 (.NET CLR 3.5.30729)] and 3.6 [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)]: "Loading error - wikEd 0.9.90d G (January 30, 2010) Click to disable" – Hgrosser (talk) 04:28, 5 February 2010 (UTC)

::Still not working for me. —Aaroncrick (talk) 06:25, 5 February 2010 (UTC)

::: Same problem here. Waltham, The Duke of 07:45, 5 February 2010 (UTC)

::::And for me too. Is it related somehow to Wikipedia:Help desk#Lost toolbar and Wikipedia:VPT#Edit box & monospace style changes? - ukexpat (talk) 15:05, 5 February 2010 (UTC)

:::::OK I got it working again by disabling "Enable navigable table of contents" in the edit tab of Special:Preferences. – ukexpat (talk) 15:08, 5 February 2010 (UTC)

::::::I had the same problem. Had to disable "Enable enhanced editing toolbar" as well before wikEd worked again. No experimental features for wikEd right now, I suppose. OdinFK (talk) 15:49, 5 February 2010 (UTC)

::::::: That worked for me, too, Odin. Thanks. Waltham, The Duke of 17:52, 5 February 2010 (UTC)

:::::::: Thanks for the hint guys, it worked. Seems the problem appeared after I played with the setting mentioned. But can any of you tell what do I miss with the two of those unchecked? – Kochas (talk) 00:27, 7 February 2010 (UTC)

It is related to the newest Usability Initiative release, I have already filed the [https://bugzilla.wikimedia.org/show_bug.cgi?id=22400 bug 22400] and work on a temporary workaround / fix. 00:38, 6 February 2010 (UTC)

I know you explained further up the page (October) that you do it on purpose so that people will see the edit notices even though the focus moves to the main edit box, but getting it to line up right is pretty hit or miss, and for pages with long editnotices it means scrolling down through two or three more screens to get to the edit box. Obviously it's just a minor annoyance, nothing major, but since this is a behavior you added with a particular piece of code I would think it would be easy to disable. -- Soap ^Talk/_{Contributions} 13:32, 5 February 2010 (UTC)

: Thanks for your suggestion, in wikEd 0.9.90e you can now add var wikEdDoCloneWarnings = false; to your monobook.js/vector.js. Cacycle (talk) 08:41, 15 February 2010 (UTC)

::Thanks! —Soap— 22:29, 15 February 2010 (UTC)

::: Thanks for the option. However, I did notice that when wikEd duplicated edit notices, it actually showed TWO copies of the edit notice below the preview. Please fix this, thanks. Gary King (talk) 18:37, 21 March 2010 (UTC)

:::: Gary King: I cannot reproduce that, please provide more information about your problem (at least a link to a page where it happens and your skin, please see the top of the page for required infos). Thanks, Cacycle (talk) 19:26, 21 March 2010 (UTC)

::::: It doesn't seem to have a problem on most pages. It does have a problem [http://en.wikipedia.org/w/index.php?title=User_talk:Dabomb87&action=edit§ion=0 here] though. Gary King (talk) 19:33, 21 March 2010 (UTC)

:::::: That is because the text between the two notices, i.e. the {{t|Statustop}} template, has been positioned out of the normal text flow to the top of the page. Cacycle (talk) 22:58, 21 March 2010 (UTC)

::::::: So why does that cause wikEd to create a second edit notice below the preview? Gary King (talk) 00:24, 22 March 2010 (UTC)b

:::::::: The two edit notices are intended. If you have another problem you need to explain it in detail as requested above. Cacycle (talk) 07:42, 22 March 2010 (UTC)

::::::::: On the link that I gave above (and in [http://i.imgur.com/uIwmK.png this screenshot]), there is one edit notice that appears above the preview, as is expected. And then wikEd creates a second edit notice below the preview, as is expected. But then wikEd creates a THIRD edit notice, which appears below the preview (I call it the "second" edit notice to appear below the preview because there are two that appear below the preview now). Gary King (talk) 16:49, 22 March 2010 (UTC)

:::::::::: I see, thanks for mentioning this, I will check into it. In the future, would you mind to be more elaborate with your your bug reports, it is always a bit frustrating and time consuming to have to squeeze the facts out of you - I cannot read your mind :-) Cacycle (talk) 08:12, 23 March 2010 (UTC)

Wikia made [http://trac.wikia-code.com/changeset/18104/wikia/trunk/skins/Monaco.php this change], and now there's another

element inside #wikia_header, making the wikEd icon go inside there, and not being shown (because of the special style that ul element has).

The logo should go inside #userData, but the way it's done you can't define #userData for the mocaco skin, because that's the ID of the

element, and your code gets the
with a getElementsByTagName, not picking the current element. You should do that instead:

if (logoContainer.tagName == 'UL') {

list = logoContainer;

} else {

list = logoContainer.getElementsByTagName('ul')[0];

}

Also, at the next line you evaluate if (list != null ), and firefox accessing a getElementsByTagName( ... )[0] when there's an empty array evaluates it as undefined and not null. It probably should never occur, though.

[http://img689.imageshack.us/i/wikiawikednodetree.png/ Here] you can view the DOM node tree of the wikia skin, where it's currently loaded the WikEd icon and where it should be placed (at the end of the bottom list) --Ciencia Al Poder (talk) 17:25, 5 February 2010 (UTC)

: I have added your changes to wikEd 0.9.90e, please could you check if it works? Cacycle (talk) 08:39, 15 February 2010 (UTC)

:: Yes! Now works like a charm!. Many thanks! --Ciencia Al Poder (talk) 21:08, 15 February 2010 (UTC)

Hi lately im experiencing that WikEd is inserting extra spaces both in the editbox and summary line, except those spaces are not regular spaces.

Example in summary line: "Copy-over from some wiki page with spaces", next time you try to re-use that text, the link will be shown as red in preview-mode of the summary, while the first time it was a correct link.

• WikEd used: v0.9.90d ({{#dateformat:2010-01-30|dmy}})
• Browser used: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
• WikEd is remote loaded by [http://wiki.fomportal.com/w/User:TriMoon/fomwiki.js personal skin-js] at [http://wiki.fomportal.com/w/Main_Page FoM-Wiki]

⇐⇑©TriMoon™ Talk @ 10:54, 4 February 2010 (UTC)

:My experience also. Happens when I copy and paste something within the editbox. I made a test edit [http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_Croatia/Recent_Articles&diff=349697763&oldid=349660568 here]: I wanted to duplicate the line, but extra whitespace was somehow introduced in the process. This was done with wikEd 0.9.90g, Firefox 3.6 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)). Apparently works fine with wikEd 0.9.90g and Firefox 3.5.8 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8). GregorB (talk) 23:24, 13 March 2010 (UTC)

::Also, extra spaces are visible only upon saving or previewing the page. Clicking on "[T]" apparently does not have any effect. GregorB (talk) 15:40, 15 March 2010 (UTC)

::: Hopefully fixed in 0.9.90h. Please could start a new topic at the bottom of this page if you still experience this problem. Thanks, Cacycle (talk) 18:18, 20 March 2010 (UTC)

I have written an alternative script to hide refs, since wikEd Beta doesn't work on Firefox 3.6 yet. It really doesn't hide refs completely, but rather it takes a simpler approach that works with plain text boxes: it replaces the first occurrence of a ref with the short code as if it were already used. Then it puts the ref's old code in a box below the main edit box. I have tested the final script on several featured articles and Comparison of Windows and Linux and with no changes to the textboxes, it does not affect the page (doesn't change the citation style on other editors unnecessarily). For more details (including how it handles unnamed refs), you will have to read the documentation and the script itself (the latter both includes informative comments and passes JSLint). The script is limited to just looking at the first ref for the contents, but this limitation should not impact its usefulness to remove the clutter of a hundred unnamed refs, for example. Despite its limitations, would you find such a script useful, since citation templates can be quite lengthy? If so, maybe the MediaWiki software itself should incorporate this idea (of course simplifying the ref format so that the content is automatically in the first ref).

My script, however, doesn't work with the Wikipedia Beta editor, which seems to be some strange code that actually removes the textarea and replaces it with an iframe (according to a quick glance at Firebug). How can I make my script Beta-compatible (like wikEd is supposed to be)?

And had you thought of the idea of moving refs into a separate box when you designed wikEd's reference hiding? PleaseStand (talk) 05:39, 6 February 2010 (UTC)

:I found the ref-hiding feature in the stable version (the "R" button at the upper right). However, as noted at User talk:SlimVirgin/templates, it can be cumbersome to use. I still support my idea of replacing refs with short codes for editing purposes but believe that the ref format should be simplified for automatic parsing. So I'd like to see this in wikEd, but preferably, I'd like to see this in MediaWiki so that it is available to all editors. PleaseStand (talk) 23:53, 14 February 2010 (UTC)

:: The only way to make your script compatible under standard textarea and the Usability Initiative beta iframe is have to separate parts of your code for them... Their iframe solution will break all existing textarea-related userscripts. I am not planning a separate ref editing window, I think the current ref hiding in wikEd beta (will be made compatible with UI-beta and Firefox 3.6 today or tomorrow) is a more intuitive and easier to edit solution.Cacycle (talk) 08:35, 15 February 2010 (UTC)

Damn. What else can I say...? Three days ago I installed the beta, since for several days WikEd had not been working, and the default editor or whatever that thing is which I keep seeing instead is rather painful. The beta didn't work either. I've tried a number of things to try to better understand it. Just tonight I disabled all my addons, theme, etc. and the result was rather underwhelming. Then, just now, coming here to post a report and ask for help, I read the comment about the beta not working with FF 3.6 - in the text of the post immediately above. Incredible. That's NOT where I should be learning about this.

Could someone put a notice up in VERY plain sight so that someone else doesn't have the experience I just had? I can't believe that this problem exists, yet at the top of this page people are still being invited to install the beta. I appreciate WikEd, and all the time that surely must have been invested in it, but people really shouldn't be installing code known to be bad, yes? Tom Cloyd (talk) 05:01, 7 February 2010 (UTC)

:Also, it seems that under Firefox 3.6, the stable version of wikEd is adding extra spaces into wikitext, as if it is trying to fully justify the wikitext. This is hard to find (spaces aren't red colored on diffs of course) and doesn't make a difference in the page as seen in a Web browser, but nevertheless, the issue seems to exist. (wikEd has had other Firefox 3.6 issues: the text cursor used to not show in Firefox 3.6.) I agree, a big notice should be posted that wikEd (neither stable nor beta) does not work properly in Firefox 3.6 and users should use Firefox 3.5 instead, and wikEd should then be fixed. PleaseStand (talk) 20:04, 7 February 2010 (UTC)

:: A diff and/or a test case would be really helpful to reproduce the issue and try to fix it. --Ciencia Al Poder (talk) 19:07, 8 February 2010 (UTC)

::: "diff"? Don't know what that is. As for test case - well, ANYTHING on Wikipedia fails, for me. I'm running Kubuntu Linux 9.10, and Firefox 3.6. Is that enough for a replication? Tom Cloyd (talk) 22:06, 8 February 2010 (UTC)

::: I have diffs, here are the links: [http://en.wikipedia.org/w/index.php?title=User:PleaseStand/Sandbox2&diff=342788594&oldid=342786949][http://en.wikipedia.org/w/index.php?title=User:PleaseStand/Sandbox2&diff=342786640&oldid=342786095]. Note that the text isn't the same in both diff links, but the common link is that I copied wikitext out of wikEd, then pasted it back in (with or without wikEd active). I'm running wikEd stable, on Firefox 3.6 on Windows 7. PleaseStand (talk) 22:10, 8 February 2010 (UTC)

::: I should add, I ran a binary compare using frhed (compares values of corresponding byte locations, not like a text diff) and the first difference I found between raw text downloads [http://en.wikipedia.org/w/index.php?action=raw&title=User:PleaseStand/Sandbox2&oldid=342786949&ctype=application/octet-stream] and [http://en.wikipedia.org/w/index.php?action=raw&title=User:PleaseStand/Sandbox2&oldid=342788594&ctype=application/octet-stream] is that {{cite web| changed to {{cite web |. And the issue only occurs when the text is copied from wikEd, not copied from the plain text editor, which has me suspecting that the browser is not copying correctly from wikEd's iframe. Bug in wikEd or in Firefox? I don't know. Cutting/pasting text is so common to reorganize pages, perhaps that's why I noticed. PleaseStand (talk) 22:30, 8 February 2010 (UTC)

::: Yeah, cut and paste is a huge problem. EOLs get inserted, and when text is pasted they are still there and have to be manually removed. A large pain. I've removed that importScript('User:Cacycle/wikEd_dev.js'); line from my skin.js page, and reloaded all pages in Firefox. It didn't fix the problem. A real mess, as I'm doing editing for hours, right now, and those renegade EOLs are a significant problem. Tom Cloyd (talk) 06:54, 9 February 2010 (UTC)

It is difficult to describe how awful this problem has become! I simply cannot cut and put in the default editor without having huge problems in randomly inserted EOLs. I do NOT know what is causing this, and certainly am not capable of figuring it out.

Can someone please attempt to replicate this? In Firefox (ver. 3.6), remove all traces of WicEd, and see if the default editor is inserting these EOLs for you as well. We need to figure this out. My thanks to anyone who can help. Tom Cloyd (talk) 10:43, 9 February 2010 (UTC)

:Yes, I have already tried that. There is no change in the page when copying and pasting an article (tested in my sandbox #2). No diff for you though since if there's no difference in the saved text, MediaWiki doesn't save the page; there is no change. This is using Monobook skin with the plain text (not experimental/Usability) editor. PleaseStand (talk) 22:04, 9 February 2010 (UTC)

:To add, I just tested the "Babaco" editor (the latest version of the Usability/Beta editor with the section jump links on the right side). You are certainly correct—it's far worse than wikEd stable in that it is actually breaking the formatting with copy-paste. Again this is on FF 3.6 and here's the diff from cutting all then pasting: [http://en.wikipedia.org/w/index.php?title=User:PleaseStand/Sandbox2&diff=343021902&oldid=343021672]. You might want to note that on the watchlist page they are warning not to use "experimental features" including the new Beta text editor. PleaseStand (talk) 22:15, 9 February 2010 (UTC)

The standard wikEd has been made compatible with the Usability Initiative beta in version 0.9.90e, I will update wikEd beta in the next few days so that it will become compatible with the Usability Initiative beta. I will also check for the EOL problem. Cacycle (talk) 08:18, 15 February 2010 (UTC)

: wikEd beta has been updated to version 0.9.91beta3.2 and is now compatible with the Usability Initiative beta changes. Please update with Shift-Reload. Cacycle (talk) 21:18, 15 February 2010 (UTC)

::!!!! It's working! Yahooo! So nice to have it back. Thanks for all your work. Tom Cloyd (talk) 19:42, 22 February 2010 (UTC)

I have serious problems with erratic cursor movements. When I run the cursor to the end of the line, it often jumps to a location much farther ahead then the beginning of the next line. Scrolling back past the beginning of a line move the cursor to a place forwards in the text. I am using window 7 and chrome 4.0.249.78. It may be related to pasting.

Can be reproduced as follows. Put "one two three four five six" in the edit buffer. Go to an empty edit screen. Paste several times to fill a few lines. Now put the cursor in the first line and scroll right past the end of it. The cursor skips the remainder of the pasted string and moves forward to the first following "one". Now scroll backwards past the begin of the reached line. The cursor does not go up one line, but reverts to the same "one" forward.

After pressing [w], I see several nested "div" blocks. Now scrolling to the right skips all remaining text.

P.S. I also experience the seemingly random insertion/deletion of empty lines mentioned by many in earlier sections.

−Woodstone (talk) 05:23, 11 February 2010 (UTC)

: This is a Webkit/Chrome bug that has already been reported (https://bugs.webkit.org/show_bug.cgi?id=34377 bug 34377). Cacycle (talk) 08:16, 15 February 2010 (UTC)

Few days ago, WikiEd could work with Wikipedia's beta features. But now, it's not working with it. So I turned WP beta off, and WikiEd works well. What should I do? -- JSH-alive ^{talk • cont • mail} 07:13, 11 February 2010 (UTC)

: I am working on it, please give me a few more days :-) Cacycle (talk) 13:46, 12 February 2010 (UTC)

:: Fixed in version 0.9.90e. Cacycle (talk) 08:12, 15 February 2010 (UTC)

I have the following error: HIERARCHY_REQUEST_ERR: DOM Exception 3: A Node was inserted somewhere it doesn't belong. Line has: "wikEdCaptchaWrapper.appendChild(node);" after comment "fill captcha wrapper with elements between form and textarea (table)" —TheDJ (talk • contribs) 15:32, 12 February 2010 (UTC)

: The standard wikEd has been made compatible with the Usability Initiative beta in version 0.9.90e, I will update wikEd beta in the next few days so that it will become compatible with the Usability Initiative beta. Cacycle (talk) 08:11, 15 February 2010 (UTC)

:: Fixed in wikEd 0.9.91beta3.2. Cacycle (talk) 08:10, 16 February 2010 (UTC)

I'm trying to use 0.9.91beta3.2 with Safari 4.0.4, and when I try to edit a page WikEd seems to load the toolbar, but the little icon in the monobook title bar at the top shows a red X and says "load error"; Safari's error console reports "ReferenceError: Can't find variable: regExpComments". I'm loading WikEd from my "monobook.js" page with this code: