User talk:Cacycle/wikEd

Please support wikEd

Please support wikEd by helping to fix the following browser and MediaWiki issues.

• Firefox:
  • 579763, 579760 Cursor/caret disappears (07-2010)
  • 1016372 Space lost when deleting text (05-2014)
  • 926230 Space at end of line not styled (10-2013)
  • 543204 Focus after search (01-2010)
  • 926164 Editor deletes blank before inserted block element when converting to text (10-2013)
  • 458524 Automatic syntax highlighting would interfere with undo/redo. The only reason why wikEd does not have automatic syntax highlighting. (10-2008)

• Webkit/Chrome:
  • None.

This is the discussion page for wikEd, a full-featured in-browser text editor that adds enhanced text processing functions to Wikipedia and other MediaWiki edit pages. Feel free to leave your comments, suggestions, and bug reports at the end of this page.

Archives

Archived discussions from this page: 1 2 3 4 5 6 7 8 9 10 11

wikEd Bug reports

In order to help you with problems, I need as many details and informations as possible:

• Your wikEd version (hover over the wikEd logo on top of every page close to the logout link). Does the bug persist if you update to the latest version (Shift-Reload or Ctrl-Shift-R)
• Your browser id (in your browsers's main menu under Help → About) (something like "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2")
• Error console errors (in your browsers's main menu under Tools → Error console; push clear, reload the page, and copy and paste the error messages)
• Which browser add-ons have you installed (in your browsers's main menu under Tools → Add-ons)
  • Optional: What happens if you disable your add-ons and restart the browser (close the quick start and the error console too)
• Which Wikipedia skin do you use (e.g. monobook or vector, please paste the following name: Special:MyPage/skin)
• Are you using the experimental Wikipedia Beta user interface (see the top left of this window)
  • Optional: What happens if you disable Wikipedia Beta
• Which user scripts have you installed on your Special:Mypage/skin.js page
• Which operating system do you use
• Describe the problem, please be as specific as possible about what is wrong (including when it happens, what happens, what is broken, and what still works)
• Steps to reproduce
• What exactly happens if you follow these steps
• Please add your bug report at the bottom of this page

Request - Pipes and Bangs

Frequently we prefer that the first row (and, less frequently, the first column) of a table to be wiki-ized as headers, i.e., with '!' delimiters instead of '|'. Do you have a way to make this happen by editing the rich text appropriately? If not, here are some suggestions:

1. If a cell is all bold, give it header style.
2. If the variable wikEdWikifyTableHeaderRow = true then header-ize first row
3. If the variable wikEdWikifyTableHeaderCol = true then header-ize first column

I like #1 the best, but of course this is your wikEd invention!

Tom.ngo 03:16, 2 October 2007 (UTC)

Thanks for the suggestion. I am thinking about a "if the first row or the first cell is bold" rule. Cacycle 12:19, 2 October 2007 (UTC)

I would personally prefer #1 - if a cell is all bold, give it header style. Tom.ngo (talk) 21:55, 19 December 2007 (UTC)

Wikia link suggest

I know that this is supposed to be available for all MediaWiki wikis, but the requests I'm asking now is specific to Wikia. Wikia has a link suggest feature described at wikiasite:help:Help:Link Suggest. However, this feature doesn't work while widEd is on. I was wondering if there's any way that you could allow link suggest to work in Wikia; it would be very helpful. Thanks. --Michaeldsuarez (talk) 01:37, 10 February 2009 (UTC)

Tricky, but I'll try... Cacycle (talk) 13:44, 11 February 2009 (UTC)

Popups with wikEd

I am a devout user of WP:POPUPS here. Normally when in the edit page, I can highlight a wikilinked word with my cursor and I get a popup like on articles. But wikEd does not allow me to do that. The ctrl-click works, but I don't want to open a new page for it, just see a preview with popups. How can I do this? Thanks! Reywas92^Talk 00:31, 24 May 2009 (UTC)

I will try to implement this, it might take a while though. Cacycle (talk) 17:56, 24 May 2009 (UTC)

Problems with fix html

In "fix html" () I found two issues

• tables don't inherit attributes (example <table class=wikitable> doesn't turn into {|class=wikitable)
• when converting, it converts new lines into <br /> in some tags like pre and math, causing malfunctions (try for example here; after fixing html, substitution <br /> -> \n gives the correct conversion) --93.47.29.46 (talk) 13:37, 18 August 2009 (UTC)

Preview background-color

Where can i change the background-color for the Preview function mentioned in Preview and changes?
Is this only possible using a css-rule or is there also a variable i can modify?
⇐⇑©TriMoon™ Talk @ 06:51, 4 February 2010 (UTC)

• PS: maybe you could change the default background-color to be "inherrit" instead of the white as it is now, that way it will look better on all wiki's because it will use the site's default colors.
  ⇐⇑©TriMoon™ Talk @ 09:11, 5 February 2010 (UTC)

Disable autoscroll?

Is it possible to selectively disable the autoscroll feature that causes the page to jump down to the edit box when loaded? I saw the previous discussion that this behavior is disabled when there's an edit notice, but I really would rather it not happen at all. I use Friendly and Twinkle, and often find myself opening a non-existent talk page to welcome or warn someone. However, wikEd jumps down to the edit box, causing the tabs to go off-screen, and I have to manually scroll back up to use my other tools. Since my browser is big enough to see the whole edit box anyway, the scrolling is more annoying than useful for me. --Darkwind (talk) 05:37, 16 April 2010 (UTC)

I will work on this as soon as I find the time after the upcoming major change to version 0.9.91. Cacycle (talk) 20:28, 20 April 2010 (UTC)

UploadForm.js not working when wikEd is enabled

Is there any way to switch of wikEd for selected articles? I have a problem with running the UploadForm-Script when the wikEd Option is active. I tried disabling loading wikEd.js (which does work wrt. wikEd not showing up), but the new upload form is still not applied. When switching off wikEd (user preferences), the new upload form is correctly applied. Thanks --StefanSchulzDe (talk) 18:30, 27 April 2010 (UTC)

How do I install UploadForm-Script? I don't think it loads when I try this and I cannot find any installation instructions. Cacycle (talk) 20:33, 28 April 2010 (UTC)

The script is loaded via the MediaWiki:Common.js script. Has some pre-requisits though, as can be seen, and I am not sure whether it can be applied via User-Scripts. I assume there is a reason, why WikEd is not available in commons. --StefanSchulzDe (talk) 17:56, 2 May 2010 (UTC)

Inserting/deleting newlines spuriosly 2 (bugreport)

• Wiked version: wikEd 0.9.91j G (July 22, 2010)
• Browser version: Google Chrome 6.0.472.33 beta
• Skin: Vector
• Link to section: User talk:Cacycle/wikEd#Inserting/deleting newlines spuriously

Here you go. ~ Boro (talk) 09:42, 12 August 2010 (UTC)

Hopefully fixed in 0.9.91k, please could you verify this? Thanks everybody for reporting and insisting on this :-) Cacycle (talk) 21:55, 15 August 2010 (UTC)

Could not reproduce the steps from the section above (Chrome 5.0.375.126/Win 7), so it looks like it's finally fixed! GregorB (talk) 07:27, 18 August 2010 (UTC)

However, it appears that newlines do creep in in some situations, i'll try to construct a test case. GregorB (talk) 10:15, 18 August 2010 (UTC)

It's a variation of the earlier test case:

1. Open e.g. this page in a new tab.
2. Type #<Enter>#<Enter>#<Enter>
3. Click on "Preview" (or on ).
4. "#" characters from the step 2 are now separated by empty lines Not any more, this has been fixed
5. Add the fourth "#" in the last line, directly below the third "#" in the edit window
6. Click on "Preview"
7. The third and fourth "#" are separated by an empty line. GregorB (talk) 11:37, 18 August 2010 (UTC)

I hope I could fix it in 0.9.91m. Cacycle (talk) 00:25, 22 August 2010 (UTC)

Cannot reproduce this in the new Google Chrome 6.0.472.53. Might be considered fixed. GregorB (talk) 22:23, 4 September 2010 (UTC)

• I've been consistently having this problem up until even today when using wikEd 0.9.100b G (September 17, 2011) in Chrome 14.0.835.202 and Vector and OS X. Test case is Military career of Hugo Chávez. Clicked edit tab, selected all text, then clicked the "Convert pasted content to plain text ..." button. Editor then inserted one newline after each paragraph.
• Further, wikEd mysteriously deletes a space before every [[, {{, and '' (there may be others in this list) that happen to be butted along the left-hand margin. If I use Firefox, no space-deletion or newline-addition issues, but wikEd becomes horrendously slow--dilatory cursor updates, general GUI flakiness, etc.
• Is there a pertinent thread for the latter issue? Otherwise, thanks for the great work. Saravask 09:48, 12 October 2011 (UTC)

Bug using wikEd on a specific website

On this website : http://fr.nvcwiki.com wikEd can be activated via gadgets preferences, but doesn't work properly.

With Firefox one can only have the right part of wikEd but not functionnal. And with Camino or Safari the edit window is to small to be visible except when set to full screen.

Thanks for your help.

--Dieudo (talk) 22:31, 6 September 2010 (UTC)

Thanks for reporting this. I could replicated this and will fix it as soon as I find some time. Cacycle (talk) 06:46, 10 September 2010 (UTC)

Text highlighter on view source page?

Would it be possible to implement the font/text highlighter on the view source page? (without the toolbars of course). — Train2104 (talk • contribs • count) 19:25, 12 September 2010 (UTC)

What is the "view source" page? Cacycle (talk) 21:36, 12 September 2010 (UTC)

The one a user gets when they try to edit a page and they don't have permission to . — Train2104 (talk • contribs • count) 21:46, 12 September 2010 (UTC)

Sure, I will add it as soon as I find some time. Thanks for the suggestion - Cacycle (talk) 22:06, 12 September 2010 (UTC)

wikEd is overwriting user customization (I give also an solution)

Hello, Cacycle! That's a very good and powerful Gadget! I have one problem/suggestion about accesskeys. You wrote "it overwrites the MediaWiki shortcuts", that's pretty fine. But You also overwrite user customization with that:

    // button access keys
    if (typeof(wikEd.config.buttonKey) == 'undefined') { wikEd.config.buttonKey = {}; }
 
    // wikEd.InitButtonKey: define accesskeys for edit buttons (wikEd button number: [key string, JS key code])
    wikEd.InitButtonKey = function() {
        wikEd.InitObject(wikEd.config.buttonKey, {
            26: ['b', 66], // wikify
            27: ['o', 79], // textify
            67: ['g', 71], // scrolltoedit2
            72: ['g', 71], // scrolltoedit3
            74: ['g', 71], // scrolltoedit4
            32: ['g', 71]  // scrolltoedit, overwrites previous wikEd buttons for same key
        });
    };

I'd like to attach 'u' to Underline button, 'i' to Italic button and 'b' to Bold button but the 'b' key seems not to work. It's attached to Wikify, I think that's because You add user customization and then set accesskeys for wikify, textify and scrolltoedit. Maybe You should reverse it?

    (...)
    wikEd.InitButtonKey = function() {
        wikEd.InitObject({
            26: ['b', 66], // wikify
            (...)
            32: ['g', 71]  // scrolltoedit, overwrites previous wikEd buttons for same key
        }, wikEd.config.buttonKey);
    };

P.S. Don't You think about archiving some sections here? q;) Vinne2 (talk) 18:57, 13 August 2011 (UTC)

Reversing the variables does not work. Please see User:Cacycle/wikEd_customization#Keyboard_shortcuts for how to redefine existing shortcuts. Cacycle (talk) 00:14, 4 January 2012 (UTC)

Links in diff link to template

Safari 5.0.2 (6533.18.5). The wiki-links in the diff link to the template of that link, so if the diff has [[Joss Whedon]] and I click it I go to [[Template:Joss Whedon]]. Templates aren't clickable at all, so this doesn't work at all, which would be extremely helpful. c Not sure when it started acting this way, maybe a week or so ago. Any thoughts?

Also, quick diff (Is that the name?) and quick preview haven't worked for a long time, I think since Safari 5. Thanks. _Xeworlebi ^(talk) 17:07, 18 October 2010 (UTC)

Will check, but it will take a while. Safari 5 seems to have several issues. Cacycle (talk) 20:49, 19 October 2010 (UTC)

Mostly fixed in 0.9.95c, still working on wikEdDiff for Safari 5... Thanks for reporting, Cacycle (talk) 23:06, 1 November 2010 (UTC)

Thanks. _Xeworlebi ^(talk) 12:37, 2 November 2010 (UTC)

Fail on bold italic text

Hello,

Some of us on frwiki have problems with wikEd when editing a page with bold italic text.

• wikEd 0.9.97a
• Firefox 3.6.13 on Ubuntu 10.10 (for me, but it looks it's not related)
• Plenty of addons (not related either)
• Plenty of other gadgets (including popups — but I don't think this is related either)
• Not related to userscripts (same behaviour with or without)
• monobook for me (don't know for the others) and no beta interface

How to reproduce :

• Take the source of this page http://fr.wikipedia.org/w/index.php?title=Utilisateur:Arktest/test&oldid=62086827 (this revision)
• Save
• Try to edit the page
• ⇒ Empty textarea

Relevant information :

 Error: parseObj.tree[openNodeIndex] is undefined
 Source File: http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript&dontcountme=s
 Line: 11679

The line 11679 is

 parseObj.tree[openNodeIndex].tag = tag; // openNodeIndex is null, the previous value of tag is “bold”

This is called by line 11147:

 wikEd.HighlightTreeRedefine(parseObj.secondlastOpenNodeFiltered, 'bold', 0, 3, parseObj); // just after case “'boldItalic':”

This is called by line 13316:

 wikEd.HighlightSyntax(obj);

With obj.whole == true and obj.html == // the whole page

If you can't reproduce, please let me know at fr:User talk:Arkanosis, I'd be happy to help.

Best regards — Arkanosis ^✉ 15:44, 8 February 2011 (UTC)

Oops. I can reproduce it and will check into it. Thanks for reporting. Cacycle (talk) 08:18, 9 February 2011 (UTC)

Req: Sort (and normalize?) list entries contained in a single line

Hi! I've got a feature request for you. Hope it hasn't been up for discussion before (boy was that ToC long – didn't dare to cast an eye on the archives too..!) Sometimes, in navboxes for instances, there are lists contained in a single table cell (e.g., Template:Beta blockers, delimited by various methods involving a bullet. Could you make the sort function sort these single-line lists somehow? Also, if possible, normalization would be neat to ensure that the method used for separating the entries (I guess " • " is the most common version) is consistent for a given line. Sometimes there is a bullet first on the line, where it's not supposed to be, sometimes people forget the   or add double spaces after the item, etc. Sometimes this can make editing the list a minor nightmare.

For now, I sorted the Template:Beta blockers by replacing the bullet stuff with newlines, opening up another WikEd tab and sorted the newly-created lines, then re-replaced the newlines with the bullet goo and pasted back in the first tab. Not so practical. :) W n C? 11:35, 23 February 2011 (UTC)

A workaround is to replace "• " with "•\n" (regex mode) then sort it afterward undo the replacement. Now I've been asked to add extra sort method (sort by last name, date, link title) to Dab solver, it would be nice to have a more powerful sorting interface. — Dispenser 04:25, 2 March 2011 (UTC)

The sort button can now sort lists in a single line, please see the wikEd help for details. Have fun, Cacycle (talk) 21:42, 6 March 2011 (UTC)

Oddly, single-line sorting doesn't seem to work for me now anymore (Safari 5.0.5, OS X 10.6.7). It just seems to mess around with the whitespace. Tried it on Template:Peripheral vasodilators. Doesn't help if I replace the &nbsp;• with e.g. {{•}}, either (though I do think WikEd could clean the ampersand mess up though, but maybe that's just wishful thinking. ;) ). W n C? 12:55, 16 June 2011 (UTC)

Extra line is inserted with regular expression replacement function if text ends a line

Happens first time, every time. Suppose I change from blogg to blog (UTC), where 'blogg' is at the end of the line. It works fine unless the regular expression button is pressed. Then an extra, blank line is inserted. Same with changing \w\wogg to blog. Text in the middle of the line works fine with or without regular expressions. Firefox 3.615 on Windows Vista, my only gadgets are Navigation popups and WikEd. Chris the speller ^yack 19:00, 8 March 2011 (UTC)

I see this too and I will check into this. Cacycle (talk) 07:44, 9 March 2011 (UTC)

Just to let you know that this is still a problem, and it effectively stopped me from cleaning up an article with a very long list. I can let the article wait, or do a whole lot of deleting lines by hand. Chris the speller ^yack 00:34, 25 June 2011 (UTC)

I omit this bug by adding "\n" at the end of the RegExp "Find" field and at the end of the "Replace" field. But it works only if You know and want to find expressions at the end of line. If that expressions are not only at the end You can add (\n?) to "Find" field and $1 (in the simpliest case) to "Replace" field. BUT: that doesn't changes the fact that I'd love that bug to be removed... q;) Vinne2 (talk) 19:10, 13 August 2011 (UTC)

Making scripts compatible with wikEd

I have installed WikEd on my wiki with the "intgrated to wikifarm" installation. I have some problem with the WikiEditor extension, when activated wiked's editing frame isn't visible. It work when you activate the fullscreen mode but the modification aren't applied. I have a mediawiki 1.16 and the WikiEditor (Version 0.2.0) extension installed with UsabilityInitiative (Version 0.1.1)

I want to do "Making scripts compatible with wikEd" installation but I don't get how it has to be done and where to paste the code --Tsouchon (talk) 13:41, 18 March 2011 (UTC)

This sounds like an incompatibility, perhaps with WikiEditor. What happens if you disable that extension? Please could you also fill out a bug report form (from the top of this page)? Do you see the wikEd logo on top of the page and does it give an error message on hovering? The "Making scripts compatible with wikEd" section is for authors of simple scripts, not for users. Cacycle (talk) 16:02, 18 March 2011 (UTC)

I have this problem too. MW version is 1.16.2. When WikiEd is on I cannot edit pages and sometimes I also get a "WikiEd Error" (WikiEd icon has a red X on it). For some reason here everything is OK... --Tharbad (talk) 19:03, 19 March 2011 (UTC)

I　got the same problem too, my MW version is 1.16.2. These two editor just work fine in zh.wikipedia.org(1.17) but not in my wiki. here is a Screenshot of the broken editor http://easycaptures.com/fs/uploaded/387/0939602272.png

PS: the small icon in right-top show as normal（There are no red X on it.）--晒太阳的冰 (talk) 04:44, 29 March 2011 (UTC)

InputBox retargets edit form

Edit this page with the above InputBox element

1. Quick preview
2. Click Save/Show Changes/Show Preview (keep the preview open)

Now you'll land on the inputbox specified page. This is because of the "title" field in the inputbox. Tested in Firefox 3.6.15 Windows XP. — Dispenser 17:42, 21 March 2011 (UTC)

This happens to me often and is very annoying. Usually I can click the back button and resubmit and it works fine, but this should be fixed. —danhash (talk) 18:21, 30 January 2012 (UTC)

"Convert to plain text" button jumps to the end

Here is a problem in Firefox 4:

1. Edit e.g. this page
2. Scroll down to the middle of the text in the edit window
3. Click on [T]
4. This causes wikEd to jump to the end of the text, instead of staying in the same position, as it does in 3.6.16 and Chrome 10

Somewhat annoying when using [T] in big articles, otherwise not a big deal. GregorB (talk) 11:18, 26 March 2011 (UTC)

This is relatively annoying, though I wouldn't imagine it's as important to fix as other things. Still, it would be convenient if the cursor was in the same position after the function completes. —danhash (talk) 18:09, 30 January 2012 (UTC)

Bug in diff.js

Hi. I found a bug in your diff.js: Look at this diff (don't care about the text, this was the example I found the bug in, and I didn't look for an English example). There is a move shown, which looks like only the comma and the space was moved. If you look at the HTML source, you can see that the deleted "also" and the inserted "wenn man" are in the moved block too, which is kind of strange. But even if you accept this to be a move, it is wrong still, since the following "einfach" should belong to the moved block too. I hope you are able to find the bug in your diff.js. --Schnark (talk) 07:29, 11 April 2011 (UTC)

In certain cases, the results are counterintuitive, especially for many close minor changes of common words and when block moves are involved. I would not call this a bug. Cacycle (talk) 17:07, 8 May 2011 (UTC)

The diff suggests that the word "einfach" wasn't changed. But it was changed: It was moved from the point where the yellow arrow shows a move to the place where it is shown in the diff. But it is not highlighted yellow as it should. The span with the class wDiffHtmlBlock should end after the word, not before it.

It should be possible to restore both the old and the new text from the diff, by omitting either the inserted or deleted blocks and by putting moved blocks either where they were or where they are now. But in this case you can only get the new text correctly in this way, the old text can't be restored from this diff. --Schnark (talk) 09:34, 10 May 2011 (UTC)

It is even possible to hide vandalism: [1] If you only look at the text marked as changed you won't notice the vandalism that occured. --Schnark (talk) 07:44, 12 May 2011 (UTC)

Screenshots to show the bug: "Vandalism is" should be yellow. --Schnark (talk) 08:31, 17 June 2011 (UTC)

• 
  What it looks like
• 
  What it should look like

Edit window size

I'd like to customize the size of the edit window in my browser and I'm a wiked user. Is there a customization bit for that, or will I need to do something special?
— V = IR (Talk • Contribs) 14:08, 19 April 2011 (UTC)

• To do that, you can drag the grip handle at bottom right of the edit window. -Pgan002 (talk) 03:39, 26 April 2011 (UTC)
  • You can chose the textarea size in your wiki preferences, wikEd keeps the default size. You can also use the fullscreen mode which is a persisting setting. Cacycle (talk) 07:03, 6 May 2011 (UTC)
    • Is it possible to calculate the text area height depending on the window height? it seems this should be already happening in

wikEd.SetEditArea(), but for me it always comes up a standard height. -Pgan002 (talk) 01:25, 24 December 2011 (UTC)

• • • Full-screen mode is great! But it should resize area dynamically if the window gets resized, or if the Find bar is shown or hidden (for example in Firefox) or a notification bar appears (in Firefox). Is that achievable? I noticed that the width does change dynamically.

Google Chrome

Google Chrome does not work. Version may be due. I'm using version 12.0.712.0 Beta.--Ğaaw (talk) 10:12, 23 April 2011 (UTC)

The latest version, 0.9.99, failed on Google Chrome 12.0.742.100 with MediaWiki 1.15.5-3 on Ubuntu Natty 11.04 64 bit and on Google Chrome (version unknown) with MediaWiki version 1.16 (I think) on Windows XP 32 bit. However, version 0.9.91o dated Aug 23, 2010 works on the Ubuntu setup. I won't know until tomorrow if it works on the XP setup. See the previous versions for the download link. --216.210.84.195 (talk) 04:00, 30 June 2011 (UTC)

I confirm this, latest working version is the one from Aug 23, 2010 on Chromium (15.0.861.0 (Developer Build 97968) Built on Ubuntu 10.10). -- Trinevahepttinette (talk) 09:23, 27 August 2011 (UTC)

Weird cursor behaviour

Hello! I'm using the WikEd, which is integrated into the German Wikipedia on Firefox 4.0 and Windows XP. I know the following two problems:

• When I remove a term which is framed by ''', the cursor will skip the last '''.
• The cursor also sometimes skips an entire line, after removing a term, which is framed by square brackets for instance.

I experience the same bug in the English Wikipedia. It is easily reproducible. Access the article Ermine_Street and try removing words out of any tag letter by letter. See what happens. --Aetas volat. (talk) 09:16, 29 April 2011 (UTC)

I will try if I can fix the first problen (it's a really tricky one). The second one seems to be a strange Firefox bug. Cacycle (talk) 21:19, 8 May 2011 (UTC)

JS errors in IE 8

After enabling the wikEd gadget on Portuguese Wikipedia and going to a page like pt:Idempotência using Internet Explorer 8.0.6001.18702 I get the following errors in the console:

Error: Type mismatch
javascript&smaxage=21600&maxage=86400, line 15568 character 3
		domElement.detachEvent('on' + eventType, domElement[eventType + eventHandler]);

and

Error: Object doesn't support this property or method
javascript&smaxage=21600&maxage=86400, line 15547 character 4
			domElement['wikEd' + eventType + eventHandler](eventRootElement.event);

Could this be fixed? Helder 20:46, 9 May 2011 (UTC)

minor bug considering new lines and highlighting

New lines created at the beginning of the document will already possess the highlighting of the following lines, no matter what you write there. It's distracting me slightly.

It's reproducible. For instance, open the page [2], go to the start of the document, press enter two times and start writing. The text will adopt the highlighting of the following lines, no matter the content. --Aetas volat. (talk) 13:30, 30 May 2011 (UTC)

Supplement: It's not just highlighting, but formatting in general. --Aetas volat. (talk) 16:03, 30 May 2011 (UTC)

Font sizes and memory usage

There are two big disadvantages I find to using wikEd: memory usage in Firefox and font sizes.

• Memory usage: one load of wikEd after some WP browsing, especially long pages, can take up 100+ MB of RAM. Several more edits can easily push the memory usage of Firefox over 550 MB, and by the time it reaches 820 MB, the browser is sluggish to the point of inusability. Restarts of the browser fix the situation, but it's very inconvenient.
  • User Note: doesn’t seem to be a problem under OS X Lion/Firefox 6 beta. Opening multiple edit windows on the entire Barack Obama article did push up RAM allocation to FF6 past 800MB (and slow things down), but memory was released once the edit windows were closed (back down to ≈525MB [still a hefty chunk]). The buglet described below, and the solution below it, still do apply on this platform, however. —Schweiwikist (talk) 10:37, 8 August 2011 (UTC)

• Font sizes: This is probably a very common complaint, but when you try and paste texts from a page title or level 1 heading, it appears as a large font size and with breaks before and after. The easy way of getting rid of the breaks involves placing the cursor after the last character of normal text and pressing "delete". But it does not work in every case and one must sometimes undo and press backspace from before the first large character. Is this one of those Firefox bugs or what? Pasting of most other text results in unhighlighted but properly sized text, which I think is perfectly acceptable.

Can you please investigate these bugs? — Train2104 (talk • contribs • count) 02:25, 25 July 2011 (UTC)

For the font size, issue, I click the "[T]" button ("Convert pasted content to plain text, update highlighting"). It works every time. Chris the speller ^yack 13:16, 25 July 2011 (UTC)

Removes empty comments

• wikEd version: 0.9.99 G; browser: Firefox 6.0; no JS errors in the console; skin: Vector; addons and other scripts: several, but problem persists when they are all disabled.

When I edit the page Template:Navbox with columns (unprotected copy at User:Ucucha/sandbox), a few empty comments get removed before I make any change to the wikitext. See the revert here. This can be reproduced by editing the page and clicking "Show changes"; it will show that these two comments are removed. This no longer happens when I disable wikEd and it does happen when I disable all other scripts and browser add-ons I have. Ucucha (talk) 23:17, 22 August 2011 (UTC)

Fixed in version 0.9.100 Thanks for reporting, Cacycle (talk) 11:42, 4 September 2011 (UTC)

And thanks for fixing it. Ucucha (talk)

Had to roll this back in 0.9.100a, but will hopefully be able to finally fix it soon. It is actually not a trivial problem... Cacycle (talk) 07:18, 7 September 2011 (UTC)

insertTags fails on empty textareas

WikEd's insertTags() fails on empty textareas. It happens mostly on Special:Upload, as the textarea in edit page mode always contains "\n".

The following patch fixes it:

Index: WikEd.js
===================================================================
--- WikEd.js	(revision 1623)
+++ WikEd.js	(working copy)
@@ -9651,6 +9651,8 @@
 //
 
 wikEd.FindBoundaries = function(word, line, para, whole, selection) {
+	if (!whole.plainArray.length)
+		return;
 
 	// get the start node and offset
 	var startNode = selection.range.startContainer;

Preview doesn't work properly in Safari

In Safari 5.1 under Mac OS 10.7, clicking on the same-page preview button (the magnifying glass) results in a generated preview where templates are not expanded, but instead appear in their source code form. Firefox works properly. Hgrosser (talk) 03:41, 1 September 2011 (UTC)

Quotation characters

Across the quick insert bar, or whatever it's called, I'm concerned about the inclusion of these ‘single’ and these “double” accents, and being able to surround words with one-click whilst the 'single' or "double" straight quotation marks do not, they only appear one at a time. Per MOS:PUNCT:

Quotation characters

Do not use grave and acute accents or backticks (`text´) as quotation marks (or as apostrophes).

There are two possible methods for rendering quotation marks at Wikipedia (that is, the glyphs, displayed with emphasis here, for clarity):

• Typewriter or straight style: "text", 'text'. Recommended at Wikipedia.
• Typographic or curly style: “text”, ‘text’. Not recommended at Wikipedia.

The exclusive use of straight quotation marks and apostrophes (see preceding section) is recommended.

I come across a lot of articles using the non-recommended style, grave and curly quotations and am quick to copy-edit. Perhaps this part of wikEd should be designed to default to, and encourage, the use of straight style characters also, to help editors out in this matter?

Ma®©usBritish ^[talk] 09:12, 1 September 2011 (UTC)

Now that you brought it to my attention, it gives me the willies, too. And those glyphs following the degree sign are not double and single straight quotation marks, but double and single primes, I think. I agree that it would be helpful to have the surround ability for the straight form of single quotation marks and, especially, double quotation marks. It would be very, very helpful for articles with lots of song titles. I once wrote my own custom button for this, but it soon caused problems. Chris the speller ^yack 14:55, 1 September 2011 (UTC)

Oh, yes now I look closely, yes they are primes.. for feet and inches, mins and secs etc 5′11″ vs 5"11' doesn't look much different in the edit box unless you squint. Still, would still help to have the inset bar with "' before ‘’“”°″′, as you say, they're a pest on pages with albums, or edited by people where English characters are not their first language and the insert bar looks convenient to use. Ma®©usBritish ^[talk] 22:18, 1 September 2011 (UTC)

wikEd has nothing to do with that - wiked is only the grey button bars. Cacycle (talk) 19:55, 3 September 2011 (UTC)

Sorry, just re-read the request. Yes, this sounds like a good idea for a fixing butten and should be relatively easy to implement. I will try to add this as soon as I find some time. Cacycle (talk) 07:15, 7 September 2011 (UTC)

Disable Pasting of Rich-text

I sort of asked this once before, but it bears repeating: Is there a way to disable rich-text pastes from being pasted as rich text? Currently, whenever I want to paste into the edit box I first paste into my search bar, then copy that text and paste it into the wikiEd editor. This method removes any formatting. Or I paste into Notepad, then copy, then paste into wikiEd. This is a huge pain. Is there anyway to make all pastes act as plain text? I only use wikiEd for its syntax highlighting as it is, and having this paste method I've devised is a bit of a hassle. --Odie5533 (talk) 11:23, 17 September 2011 (UTC)

Unfortunately not because this is done by the browser, not by wikEd. There is no reliable way for JavaScripts to intercept these events. I know it is a major annoyance. Cacycle (talk) 16:30, 17 September 2011 (UTC)

Perhaps an option to automatically remove the highlighting by pressing [T] after a user performs a paste, and then return to the right cursor position? Currently pressing [T] selects all. --Odie5533 (talk) 22:59, 17 September 2011 (UTC)

Please see also User:Cacycle/wikEd help#Automatic syntax highlighting for more details. Cacycle (talk) 19:29, 18 September 2011 (UTC)

You could add a "Plain-text pasting" text input field to the WikEd toolbar. Pasting text into it would automatically insert that text at the cursor position (or replace the selected text) in the text area. It could be done as a text input field above WikEd through a user script, but it would be nicer if it is a built-in function. --V111P (talk) 03:49, 24 December 2011 (UTC)

Ok, apparently you can use Shift+Ctrl+V to paste as plain text in Firefox and Chrome. Chrome even has an option "Paste as plain text" in its right-click context menu. --V111P (talk) 02:41, 25 December 2011 (UTC)

New Wiki Look Compatibility

Is there any way to use WikEd as a userscript with the new Wiki look (Oasis I belive)? --Pichu659 (talk) 10:59, 26 September 2011 (UTC)

Tabbing

Did something change with the tabbing? For some mysterious reason, tabbing out of the edit textarea to the edit summary now fails to select the content of the edit summary (instead inserting the cursor at the beginning of the input), which is the behavior behavior anywhere that I know in computing. Circéus (talk) 16:48, 14 October 2011 (UTC)

Sig Button

This is probably the only feature to be added with WikEd. On user talk pages its annoying to have to toggle between the standard toolbar and wiked only. --Kangaroopowah 22:21, 23 October 2011 (UTC)

Ref hiding bug

In this edit I used the "[REF] and [TEMPL] hiding" feature to make the text easier to edit, but it removed the </ref> tag at the end. —danhash (talk) 18:35, 31 October 2011 (UTC)

Cannot get wikEd to display at all. Followed instructions, but still no dice.

I've installed the extension completely on my site. I'm trying to set it site wide. I've added the lines to the localsettings file, added all of the .js pages to my install. Tried it both as a gadget, and as a full local install. No dice either way.

Anyone care to take a look, I'd be happy to provide you access. I'm just not sure what I'm missing. --Fadmwheeler (talk) 03:46, 22 November 2011 (UTC)

Please could fill out the bug form (see top of the page)? Please feel free to send me your site's details using the E-mail this user page. Cacycle (talk) 13:35, 26 November 2011 (UTC)

WikEd version is the latest version. I've tried this is IE 9, Firefox, Chrome, and Safari to no avail. (I am a coder myself, so I generally verify which platforms will function for my users). No errors, the addin just doesn't load at all, it's like it's ignoring the commands all together. No browser add-ons except Java. No affect if i disable the add-ons. Using Pixeled skin, although i've tried it in MonoBook and Vector as well to no avail. (We have moved some items in CSS in pixeled, so i understand it wont look EXACTLY the same, but we have tried it in the out of the box monobook and vector styles as well. Using Windows XP and Windows 7, no change in either. The problem is simple, the script just doesn't load. There is no evidence that it is ever taking affect. I have e-mailed you my site information. I appreciate your help! Fadmwheeler (talk) 15:24, 27 November 2011 (UTC)

Your problems are caused by 1) the semicolon at the end of line 21 in your MediaWiki:Common.js (see your error console) and 2) by the Pixelated skin (I have added support for it to the next release going online soon). Cacycle (talk) 23:32, 13 December 2011 (UTC)

It should work now, please update your copy of wikEd to version 0.9.102 (January 03, 2012) (or, even better, load wikEd from its official page so that you get updates automatically). Cacycle (talk) 11:45, 4 January 2012 (UTC)

Cacycle - thank you so much it does in fact work now! (talk) — Preceding unsigned comment added by 99.118.198.202 (talk) 05:22, 7 January 2012 (UTC)

window.wikEdUseWikEd is undefined

window.wikEdUseWikEd is undefined even when WikEd is on, so old scripts can't detect WikEd and some of the examples in WikEd's documentation don't work. (Firefox 6 & Chrome 15, Windows OS, wikEd 0.9.101, Vector skin.) --V111P (talk) 04:00, 2 December 2011 (UTC)

Please could you provide more details? Why exactly do you think that window.wikEdUseWikEd is undefined? Please also provide details about your system and configurations (see the top of the page for the bug report form). Which examples do not work? Cacycle (talk) 19:10, 3 January 2012 (UTC)

I can confirm that this is a bug in the current version of wikEd. My script is no longer working correctly with wikEd because it tests this variable per the guidance, and it is undefined. My script worked with previous versions of wikEd. —GregU (talk) 21:03, 16 February 2012 (UTC)

Insertion of special characters fails

I'm using wikiEd as a gadget in ro.wp and en.wp on Firefox 7. I've noticed that if I try to insert a character from the new Vector toolbar, it only works on the first click. On subsequent clicks, the cursor jumps around, but nothing else happens. Debugging with Firebug, it would seem that everything goes ok until the execCommand('insertHtml'), which for some reason fails. If I disable wikiEd, everything goes back to normal. Has anyone else seen this behavior?--Strainu (talk) 08:23, 17 December 2011 (UTC)

Fixed in wikEd 0.9.102 (January 03, 2012), thanks for reporting. Cacycle (talk) 19:06, 3 January 2012 (UTC)

How can I disable thumbs within syntax highlighting?

When syntax highlighting is enabled, thumbs of used images are shown within the text editor window. This is confusing and buggy (tiny images are repeated to fill a certain width). How can I dsiable those thumbs while keeping normal syntax highlighting? --Subfader (talk) 15:22, 30 December 2011 (UTC)

Images are only repeated when the image size parameter is not set (e.g. instead of ). It is not exactly a bug as there is no other way to implement this without knowing the image size. In order to turn image preview off, you might try

wikEdConfig = { 'filePreview': false };. See User:Cacycle/wikEd customization for details. Cacycle (talk) 19:18, 3 January 2012 (UTC)

Thanks a lot that worked :) --Subfader (talk) 19:04, 4 January 2012 (UTC)

wikEdDiff and Special:ComparePages

Just letting you know that wikEdDiff explodes when using it on Special:ComparePages. →Στc. 04:50, 16 January 2012 (UTC)

Please could you give me enough infos to replicate this (please see the top of the page for a bug report form)? Thanks, Cacycle (talk) 23:06, 23 January 2012 (UTC)

Convert MS Word to Wiki?

I've read several times that wikEd can convert text from MS Word, but I can't see how? — Preceding unsigned comment added by Subfader (talk • contribs) 12:40, 17 January 2012 (UTC)

Copy from Word, paste into the editing area, and push the wikify button . Please see the User:Cacycle/wikEd help for more background. Cacycle (talk) 07:38, 23 January 2012 (UTC)

Whitespace "fixing"

Is there a way to move all whitespace "fixes" and changes of any kind to a separate function which does not run unless explicitly invoked? The AWB RegEx function in particular is pretty much useless if it screws around with whitespace in addition to the useful RegEx fixes. In instances where the RegExTypoFixer rules may manipulate whitespace, perhaps all edits that would have been made could be ignored if they only affect whitespace. Other functions such as "fix html to wikicode" are very annoying to use with all the unnecessary whitespace editing. I end up selecting small areas and running the tool on them individually, which is tedious and annoying. AutoEd and other automated tools work with whitespace too and often end up undoing each other's edits (for example, spaces in between headings and equal signs). —danhash (talk) 16:15, 26 January 2012 (UTC)

These whitespaces make articles much easier to read, so I do not really see a reason not to add them (unless the implementation should be buggy and adds spaces where they are not supposed to be). Cacycle (talk) 16:59, 28 January 2012 (UTC)

See here and here for examples of how script-based whitespace edits can cause problems and scripts can step on top of each other with needless edits. This isn't the only problem though—very often when I use one of wikEd's "fixes", numerous newlines are inserted. I believe there are at least 2 or 3 separate sources of the unwanted whitespace addition/removal issue:

• Extra newlines are often inserted when editing a page. One example where this happens to me almost every time is on this user page. Typically I click edit, place the cursor at the beginning of the bulletted list, hit enter, and create a new line. When I hit [W], most of the time a newline is added after the line I just created (even if I don't click [W], the line shows up when I save the page or preview). This sounds similar to the "Inserting/deleting newlines spuriosly 2 (bugreport)" section also on this page. I actually just experienced this issue again, when previewing this edit.
• Often, regular copy/paste edits remove newlines, leaving two words mashed together. This bug is not always apparent until re-reading a section and noticing grammar errors where there were none before. This is particularly annoying when copying content from one page to another (for example for archiving a talk page) where a regular diff will not show the error.
• The word wrap feature seems to have a bug that causes the removal of spaces when editing lines of text.
• When using the "fixes" I often just apply the fix to a small section of a page that I manually highlight, because using fixes (especially on a large page) often making unintended (and very annoying) unnecessary whitespace (and newline) changes. Even if some of this extra whitespace "should" be there, if I want to add it, I should be able to choose to do so via a separate function, separate from other fixing functions. For example, if I was going to apply these whitespace "fixes", I would do so as the last step of editing a page. Often it takes a succession of fixes and various edits to clean up a page, and screwing with whitespace every step of the way introduces more problems and annoyances than it fixes. Also, if I am editing a talk page, I have no intention to "fix" the whole page by changing the posts of numerous other editors. The presence or absence of whitespace in the source in and around headings is a style/MOS issue and is not something that should be forced on users by a user script.

To conclude: 1. whitespace should not be changed by a script unless that script is asked to do so, and 2. there are some bugs in wikEd's handling of whitespace. —danhash (talk) 15:31, 30 January 2012 (UTC)

The "newlines added by [W]" issue may be a result of a misinterpretation on my part of what the button is supposed to do. I believe that most circumstances where I have been clicking [W], I should have been clicking [T], since my intention is to end up with plain text, disregarding any formatting that has been pasted. —danhash (talk) 14:29, 2 February 2012 (UTC)

Show source button

No matter what I do I can't get the show source button () to show up. I've tried my current common.js in Firefox and Chrome; am I doing something wrong? —danhash (talk) 18:50, 26 January 2012 (UTC)

Got it. The variable name is "showSourceButton", not "wikEdShowSourceButton". —danhash (talk) 18:58, 26 January 2012 (UTC)

Seems like a number of settings in the documentation are listed as "wikEd*" instead of "wikEdConfig.*". —danhash (talk) 19:12, 26 January 2012 (UTC)

Plain pasted text?

Sorry if this isn't the right page to ask this on, but is there a way to force any text that's pasted into wikED to be plain text? It's really annoying when I copy things in from other sites and it keeps the font style, sometimes even the page's formatting gets through and screws up the whole page. I hate having to copy text through Notepad in order to change it to plaintext. Thanks very much for the assistance and keep up the work! I love this extension! 76.172.107.173 (talk) 17:52, 30 January 2012 (UTC)

Check out this thread which addresses the issue. The short answer is to use Ctrl-Shift-V to paste instead of Ctrl-V, or to right-click and select "Paste as plain text" in supported browsers. —danhash (talk) 18:05, 30 January 2012 (UTC)

I am actually working on this. Unfortuntely, Ctrl-Shift-V does not work in most cases. Cacycle (talk) 00:09, 4 February 2012 (UTC)

Chrome: Hotkey «Alt-S» not working for saving article

• Firefox+Wiked: «Alt-Shift-S» works OK for saving, both focus on textarea or page
• Chrome:
  • Without Wiked: the hotkey works.
  • With Wiked:
    • Hotkey «Alt-S» works if focus is on page and outside textarea.
    • Hotkey «Alt-S» does not work if focus on textarea.

Can this be fixed? Or possible can submit bug request for Chrome? --StasFomin (talk) 14:14, 2 February 2012 (UTC)

Wiked + Firefox = "_moz_dirty" + "empty font"

Follow up to User talk:Cacycle/wikEd/Archive 011#Some bugs in WikEd 0.9.99 and Firefox 5

• Does it still do this in Firefox 6? Please could you give me an example of pasted text where this happens?

A lot of such issues active even in FF10.

Demo:

• Open http://wiki.4intra.net/public/bugs/moz-dirty-wiked-issue.html
• Select and copy from "77777" to "2222"
• Paste to wiked in FF
• Wikify by Wiked

• Results:

<font>'''''77777'''''</font>
3333333

name="cutid1" _moz_dirty=""[1:27:18] 44444444

[1:57:48] 2222

Annoying issues:

• " _moz_dirty" crap
• empty tags "font"

Please, give some ideas how to fix it (submit bugs to FF? may be regexp heuristics after wikifying? …) --StasFomin (talk) 16:57, 2 February 2012 (UTC)

I will fix this in wikEd as soon as I find the time. Cacycle (talk) 00:07, 4 February 2012 (UTC)

It was a stupid bug and has been fixed in the upcoming version. Cacycle (talk) 15:28, 4 February 2012 (UTC)

wikiEd replaces the non breaking space (U+00A0) character with space (U+0020)

• wikiEd version: latest (the one from this page)
• browser: Some version of Firefox, the user would not say. I was able to reproduce it using FF9.0.1 on Windows.
• skin: Monobook (is reproducible also using Vector)
• problem description: when editing a page containing non-breaking space characters (for instance ro:Lista_monumentelor_istorice_din_România/Alba), wikiEd replaces character U+00A0 with character U+0020, creating incorrect line separations.
• workarounds: disable wikiEd :)--Strainu (talk) 21:30, 6 February 2012 (UTC)

This is a complicated and difficult issue. The general consensus was that the only reliable, transparent, and safe way to use non-breaking spaces in articles is the character entity &nbsp; instead of the actual character. Cacycle (talk) 08:12, 10 February 2012 (UTC)

That is in en.wp and does not apply to other projects. :) I second the suggestion made above to prevent any automatic whitespace change.--Strainu (talk) 22:02, 10 February 2012 (UTC)

The en:wp guideline exists because it is technically as well as from the editing side not possible to reliably preserve non-breaking spaces. It is definitely not possible in wikEd without some major design changes. This has been discussed in depth and repeatedly, e.g on Wikipedia:Village_pump_(technical) (check the archives). Sorry, Cacycle (talk) 13:18, 11 February 2012 (UTC)

Dup: Non breakable spaces (Alt+0160) are automatically changed to normal spaces

wikEd 0.9.102 G (Jan 03 2012), Chrome 18.0.1025.39 beta-m, I believe there are no console errors, addons do not interrupt, skin vector... anything else? :)

When typing the Alt+0160 shortcut it inserts non-breakable space (NBSP). But when editing in wikEd it saves it as normal space everytime when:

• you hit Save,
• you hit Preview (and you do not have the dynamic one turned on),
• you hit Changes,
• you switch from wikEd to normal text area during editing.

That causes every NBSP between a number and unit (e.g. "40 mph") be changed to normal space allowing word wrap there. Yes, we can write   there but that's ugly and hard to understand for newbies that'll try to edit an article or correct one value. Vinne2 (talk) 23:48, 26 February 2012 (UTC)

Please see the section "wikiEd replaces the non breaking space (U+00A0) character with space (U+0020)" above, a recent discussion of the same thing. Chris the speller ^yack 01:05, 27 February 2012 (UTC)

Merged the threads. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contribs. 12:25, 27 February 2012 (UTC)

Reusing User:Cacycle/diff.js

Hi, thanks for your work. I am going to use it in commons:MediaWiki:VisualFileChange.js for the regexp-replace-examination. That's all. -- Rillke (talk) 16:44, 13 February 2012 (UTC)

Great! Let me know if you have any questions or suggestions! Cacycle (talk) 07:53, 14 February 2012 (UTC)

Firefox 10.0.x/Windows issue - Blurry text when normal text is selected

A few days ago the highlighting of selected normal text suddenly changed, from normal white characters on a blue background to extra bold, fuzzy white on a blue background, making the text nearly impossible to read. Text that is already highlighted (e.g. lists, templates, images) is still the normal white characters on a blue background when selected. The selection can be manually done or as the result of a search. I'm willing to swear on a stack of dictionaries that I haven't changed anything on my end. I don't think I have upgraded Firefox (10.0.1) recently. I am running Windows Vista Home Premium, Service Pack 2. Is anyone else having this problem? Chris the speller ^yack 22:50, 13 February 2012 (UTC)

I'm not seeing this. I'm running the same OS with Firefox 9.0.1. It might be a Firefox 10.0.1 issue; 10.0.1 was just released this past Friday (and 10.0 is barely two weeks old). jcgoble3 (talk) 23:18, 13 February 2012 (UTC)

Thanks for the info. I guess I wasn't paying much attention to Mozilla; maybe I have trusted them too much. I went back to 10.0.0 and that didn't help. I am trying to find 9.0.1 from a site that doesn't jam a lot of malware onto my browsers. Will report back. Chris the speller ^yack 01:19, 14 February 2012 (UTC)

Here's the grim news: I don't see the problem with Firefox 9.0.1, so it appears to be a Firefox 10.0.0 issue, and 10.0.1 does not fix it. I am going to adjust the name of this section to put the blame square on the new version. — Preceding unsigned comment added by Chris the speller (talk • contribs)

I am not seeing this in Firefox 10.0.0 or 10.0.1 (just updated) on Mac OS X 10.5.8. Ucucha (talk) 01:49, 14 February 2012 (UTC)

Alright, then it sounds like the problem is limited to Windows as well. Added to the header. jcgoble3 (talk) 02:17, 14 February 2012 (UTC)

This is a change/bug introduced with Firefox 10. I have already filed a bug report a few days ago, see bug 721750 and bug 724241 and it is currently being resolved. Cacycle (talk) 07:48, 14 February 2012 (UTC)

An utterly fatal flaw - loses state and flushes all changes if you navigate away and back in same window

Well, wikEd is superlatively badass, but I can't use it. It's already cost me hours and hours of work because of the way I edit. For years, I've always recycled the same editing window to move back and forth between things while editing. E.g., I might be editing an article and inserting a template and forget what a parameter is called, and edit the URL bar to go the template documentation, then hit "Back" to finish editing the article, and remember something I saw earlier and hit "Back" 5 times to go copy it, then "Forward" 5 times to get back to editing and paste that in and save all these changes. This is impossible for me (Firefox 10.0.2, Mac OS X 10.7 Lion), because all changes made in the editing window are flushed if you navigate away and back, when wikEd is running. Practically makes me cry (not just for the lost work, but because I've been waiting for years for something like wikEd and was very excited about it). — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contribs. 12:23, 27 February 2012 (UTC)

This bug is caused by another script, please see bug 22680. Cacycle (talk) 22:07, 24 March 2012 (UTC)

I have this same problem on Wikia in the Monobook skin. My JS page is here. jcgoble3 (talk) 23:59, 24 March 2012 (UTC)

Very slow to load

With WikiEd 0.9.102G, the edit page takes about 10 seconds to load on my fast computer. The edit page loads the text, then adds syntax highlighting, and finally the WikiEd toolbar loads. Is there any way to speed this up? Here's my info:

Windows 7 x64 Home Premium

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0

WikiEd 0.9.102G My Monobook skin

--Yutsi ^Talk/ Contributions 15:49, 28 February 2012 (UTC)

Inserting characters from the Vector toolbar

Suddenly all the vector toolbar buttons appear to have stopped working. If I click on any of them then rather than appear here in the edit box they appear in the section subject/heading box, if I opened the page using new section, or don't appear at all if I opened the page any other way. I can only use the buttons with wikEd toggled off which is a bit of a bind. And now the edit window is pointing out spelling errors which I don't recall before. Great for plain text, a bugger for code and markup. I'm running wikEd 0.9.102 GM (I get the same problem using 0.9.102 G with Greasemonkey switched off), Firefox 9.0.1, Windows 7 (64bit), Vector skin NtheP (talk) 16:56, 1 March 2012 (UTC)

All seems to be resolved today. Perhaps my laptop had a 24 hour bug? NtheP (talk) 12:46, 2 March 2012 (UTC)

Problem editing refs since MediaWiki upgrade.

Since the latest MediaWiki upgrade, it appears that WikiEd is preventing me from editing any refs. If I try to edit a page, instead of the detailed citation, I just see a grey button labelled "ref". There is no way to display or edit the ref itself. I blanked and reinstalled my vector.js page, and found that deleting WikiEd resolves the problem. I don't know what version I was using, but I tried reinstalling through the Gadgets menu, and the problem recurred. I edit using Firefox 10.0.0.2. I've posted a screenshot here of the problem. RolandR (talk) 22:16, 1 March 2012 (UTC)

See User:Cacycle/wikEd_help#wikEd_control_buttons, first row of the table. jcgoble3 (talk) 22:37, 1 March 2012 (UTC)

OK thanks. So something in the upgrade altered the default setting for this, since I certainly changed nothing since it was working last night. RolandR (talk) 22:55, 1 March 2012 (UTC)

Documentation for gadget authors

We're trying to start a library for gadget authors to use. Please check it out and post any questions or comments there. -- ☠MarkAHershberger☢(talk)☣ 01:02, 9 March 2012 (UTC)

Template unhiding doesn't work

With 0.9.102 (FF 10.0.2 Ubuntu, Monobook), if you have template (and char entity) hiding turned on with the "R" icon, it doesn't unhide when you click or mouseover the template box. I have fixed this by going back to 0.9.101 by installing the development version (by adding importScript('User:Cacycle/wikEd_dev.js'); to my common.js). Also, you might want to update all your documentation to refer to common.js, rather than monobook.js, etc.
On an unrelated note, sortable tables don't appear as sortable in WikEd's previews; but it's not your fault, as they don't appear in Wikipedia's built-in preview. Hgrosser (talk) 17:06, 11 March 2012 (UTC)

Problem with processing OSed diffs

Hi, you might want to take a look at the discussion at mediazilla:35153. Thanks. It Is Me Here ^{t / c} 17:56, 18 March 2012 (UTC)

Problem with Word

Hello, when I copy text from MS Word 2010 or 2007, and then when i publish it, this sentence : Normal 0 21 false false false FR X-NONE AR-SA apperas on the top of my text. You can see that here

my version is : 0.9.102 Sorry for my english, I hope you understand the problem. thanks. Rabah201130 (talk) 10:37, 20 March 2012 (UTC)

Better link to show the problem: [3] jcgoble3 (talk) 17:58, 20 March 2012 (UTC)

User script listings cleanup project

I'm leaving this message for known script authors and recent contributors to Wikipedia:WikiProject User scripts/Scripts.

This scripts listing page is in dire need of cleanup. To facilitate this, I've created a new draft listing at Wikipedia:WikiProject User scripts/Scripts cleanup. You're invited to list scripts you know to be currently working and relevant. Eventually this draft page can replace the current scripts listing.

If you'd like to comment or collaborate on this proposal, see the discussion I started here: Wikipedia talk:WikiProject User scripts#Scripts listing cleanup project. Thanks! Equazcion ^(talk) 00:19, 25 Mar 2012 (UTC)

Little search & replace bugs in regual expression mode

1. When you try to search for a regular expression from the history drop-down list, it won't work if it contains a space. However, if you replace that space with a new space, it works. Example: search for the history in Regular expression mode. Now search for something else, then try to search for the history again by selecting it from the drop-down list. It won't work. Replace the space between the and history with another space. Now it works again.
2. When replacing text at the end of the line in Regular Expression mode, an extra new line is inserted after the replacement.

--V111P (talk) 01:41, 25 March 2012 (UTC)

Template unhiding doesn't work (with a clue)

Please check at lines 656-7-8.

User:Cacycle/wikEd.js
wikEd.programVersion = '0.9.102'
// wikEdFrameBodyNewbie ref and template hiding

I think problem comes from left: -10000em; and position: fixed;
Without these properties (I tested by deleting them in the CSS through Firebug), unhiding seems to work again. However, I have not tested if this could harm some other feature. -- Codicorumus  « msg 14:58, 25 March 2012 (UTC)

Same at lines 672-73.

'.wikEdFrameBodyNewbie .wikEdCharEntity, .wikEdFrameBodyNewbie .wikEdCharEntityShow':

This time I've tested patching the js file. After deleted said properties and changed display: block; to display: none; in both instances, hiding/unhiding seems to work well.

Was it a patch for an unresolved bug ?  If that's the case, could you give me any hint for replicating that bug ?  -- Codicorumus  « msg 04:55, 26 March 2012 (UTC)

Fixed in 0.9.103b. Sorry for this. Cacycle (talk) 21:25, 8 July 2012 (UTC)

Thanks a lot.

Just another small thing that I forgot to report: a missing dot at line 664 (programVersion = '0.9.103b'):

'.wikEdFrameBodyNewbie wikEdRefContainer + .wikEdRefShow, ...
                       ^

-- Codicorumus  « msg 15:11, 9 July 2012 (UTC)

Fixed in 0.9.103c, thanks a lot, Cacycle (talk) 21:45, 9 July 2012 (UTC)

instant preview not working

0.9.102 Firefox 11 all addons disabled apart from wikEd/greasemonkey default skin no other scripts Windows XP sp3

I pasted the contents of the firefox error console at http://en.wikipedia.org/wiki/User:Lemonbalmtea/sandbox/paste

Whenever I try to use the "preview" function of wikEd to show a live preview of an article without reloading the page, the preview doesn't appear. All that appeasr is a text box containing "..."

Clicking the preview button again adds an additional blank line to the text box

Lemonbalmtea (talk) 14:25, 10 April 2012 (UTC)

I see this too, I will check into it. Cacycle (talk) 16:48, 8 July 2012 (UTC)

Dashes

What exactly does the "fix dashes" function do? It doesn't seem to do much of anything related to dashes (for example it doesn't change spaced hyphens to spaced en dashes). It does, however, make totally unnecessary and annoying whitespace changes. Is its function supposed to be at all similar to dashes.js? —danhash (talk) 15:01, 10 April 2012 (UTC)

Currently, it does the following:

• convert html character entities into actual dash characters
• remove spaces around em dashes
• convert -- to em dashes
• convert hyphen next to lone number into a minus sign character
• convert minus or en dashes to dashes with spaces
• convert dashes to en dashes in dates

Functionality from User:GregU/dashes.js could be added, but inter-language compatibility would be very important. Cacycle (talk) 16:42, 8 July 2012 (UTC)

Recent change?

Has there been a change to wikEd or MediaWiki lately? In the last several days wikEd has often not been loading (on two different computers using both Chrome and Firefox). —danhash (talk) 14:27, 23 April 2012 (UTC)

Copy-paste-ing

When I copy-paste something from somewhere, there will be an extra space in the beginning and the end. Did you make it on purpose?--Kc kennylau (talk) 12:44, 24 April 2012 (UTC)

See the section Disable Pasting of Rich-text above for a solution. --V111P (talk) 17:57, 24 April 2012 (UTC)

Maybe he could make an option called "always paste as plain text". --Kc kennylau (talk) 12:51, 26 April 2012 (UTC)

I have already worked on this, but it is not yet ready for a roll out. Cacycle (talk) 16:44, 8 July 2012 (UTC)

Getting RETF to work

I've just installed WikEd. First I did it by setting my Preferences, and that brought WikEd up when I went into edit an article but the RETF button wasn't displayed. Then I discovered that I was supposed to add some code to my monobook before the WikEd installation code, so I switched off the gadget preference and instead added the installation code to my monobook, with the RegExTypoFix code line immediately before it. However, I've tried reloading monobook, logging and off Wikipedia, closing and reopening the browser (Chrome), but the RETF button still doesn't appear (the box on the toolbar beside the 'fix units' button is blank. This is what I've got now in my monobook:

wikEdRegExTypoFix = true;
// install User:Cacycle/wikEd in-browser text editor
document.write('<script type="text/javascript" src="'
+ 'http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js'
+ '&action=raw&ctype=text/javascript"></script>') ;

How do I get RETF to work? Colonies Chris (talk) 13:49, 22 May 2012 (UTC)

Please see below for the answer... Cacycle (talk) 16:33, 8 July 2012 (UTC)

Double editnotices

Whenever I use wikiEd all editnotices are displayed double. Am I the only user having this problem? If it's any help, I use Google Chrome on a Mac.  Liam987(talk) 08:17, 25 May 2012 (UTC)

It's a feature, not a bug. See User:Cacycle/wikEd help#Double edit notice. jcgoble3 (talk) 13:39, 25 May 2012 (UTC)

OK  Liam987(talk) 14:21, 26 May 2012 (UTC)

Question about the editor

I have just installed the wikED today and I'm loving the available options this has added to editting a page. But I have a question: While copy and pasting information from our forums site to transfer to mediawiki it kept the same format as on the forums. Awesome, I thought, But when I clicked preview, the format was dropped and replaced with plain txt. Screenshot of both formats (image hosted on photobucket) My LocalSettings.php is set to allow external images. Is there any way I can keep that format that's in the above edit window? I'm just confused that it would show it exactly how I want it then when I save the page it becomes plain text. Thank you for any help with this ^^ Benitora Masaki (talk) 22:10, 1 June 2012 (UTC)

You need to click on the wikify ([W]) button after pasting. --V111P (talk) 14:36, 3 June 2012 (UTC)

I've done that and it still loses the original format. Oh well, thank you for the reply. Benitora Masaki (talk) 18:34, 3 June 2012 (UTC)

Bracket matching

Any plans to add bracket matching? ··gracefool☺ 19:45, 20 June 2012 (UTC)

Interesting idea, maybe in the future. Cacycle (talk) 16:31, 8 July 2012 (UTC)

Getting RETF to work

Raising this question again because I still can't get RETF to work.

I've just installed WikEd. First I did it by setting my Preferences, and that brought WikEd up when I went into edit an article but the RETF button wasn't displayed. Then I discovered that I was supposed to add some code to my monobook before the WikEd installation code, so I switched off the gadget preference and instead added the installation code to my monobook, with the RegExTypoFix code line immediately before it. However, I've tried reloading monobook, logging and off Wikipedia, closing and reopening the browser (Chrome), but the RETF button still doesn't appear (the box on the toolbar beside the 'fix units' button is blank. This is what I've got now in my monobook:

wikEdRegExTypoFix = true;
// install User:Cacycle/wikEd in-browser text editor
document.write('<script type="text/javascript" src="'
+ 'http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js'
+ '&action=raw&ctype=text/javascript"></script>') ;

Colonies Chris (talk) 15:07, 26 June 2012 (UTC)

You have to use var wikEdConfig = {}; var wikEdConfig.regExTypoFix = true; instead, as described on User:Cacycle/wikEd_customization. This also works for wikEd as a gadget. Hope this helped, Cacycle (talk) 16:27, 8 July 2012 (UTC)

OK, I've removed the monobook WikEd installation code, added var wikEdConfig = {}; var wikEdConfig.regExTypoFix = true; at the bottom of my monobook, and switched on WikEd as a gadget on my user preferences page. But I still don't get RETF - the button on the toolbar beside the 'fix units' button is blank. Colonies Chris (talk) 11:25, 19 July 2012 (UTC)

I am in the same boat. Chris the speller ^yack 13:54, 19 July 2012 (UTC)

Hit Preview, work disappears

Has a change been made recently? A couple times recently, I've written something, then hit the Preview button and saw no changes and my edit box reset to how it was before the edit. As you can imagine, this is incredibly frustrating. As useful as this tool is, I obviously can't deal with work being arbitrarily erased. -- tariqabjotu 04:44, 10 July 2012 (UTC)

Sorry to hear this. Please could you give some more details? Please see the top of the page for the bug report form. Did you use the standard preview button or wikEd's 'show preview below' button? Cacycle (talk) 06:29, 10 July 2012 (UTC)

I used the standard preview button (as I've always done). I can't really give details of how it happens. It just happens sometimes. I write something. I press "Preview" and I don't get a Preview, and I get the edit box how it was before I even began editing the section. It's not just on specific pages. It's not at specific times. However, it seems like it only happens when I've been editing a page for a long time and have had it open for awhile (at least thirty minutes). In other words, the issue occurs at the time of maximal inconvenience. And it seems to know when I didn't copy and paste it into a second document before attempting the preview. The fact that no one has apparently complained about it suggests it's just me, though. But I'm not sure why. I've used wikEd for years without issue, and it's happened at least a half dozen times now since the beginning of July. -- tariqabjotu 19:28, 14 July 2012 (UTC)

Some basic details about m computer: I'm on a Mac OS X v. 10.6.8 and I edit using Chrome v. 20.0.1132.57. My wikEd version is 0.9.103d G (July 11, 2012). -- tariqabjotu 19:39, 14 July 2012 (UTC)

I've just experienced the same thing a couple of times; my setup is Chrome, Windows 7 on a PC. Colonies Chris (talk) 09:53, 20 July 2012 (UTC)

I'm in the same boat here (Chrome @ Windows XP right now). There's a particular edit I'm repeating since an hour or so to pinpoint the problem (I disabled all extensions in Chrome) and it turns out to be wikEd. I'm not applying the edit for now, to see if we can solve this issue.

I also note that since some time now, wikEd insists on adding extra spacing around my edits, which I have to correct after a preview. I'm wondering now if this is normal behavior. --Langus (t) 22:33, 21 July 2012 (UTC)

Please could you describe in detail what you mean by "insists on adding extra spacing around my edits", which preview you use, and which browser and OS you use (see bug report form on top of the page)? Thanks, Cacycle (talk) 20:26, 1 August 2012 (UTC)

I've experienced this spacing bug in recent versions of Chrome on Windows XP, Windows 7, and OS X 10.6.8. It seems to happen when I use the wikEd ajax preview button. Tuvok[^T@lk/_Improve] 02:45, 3 August 2012 (UTC)

I would love to help, but without a detailed bug report I cannot reproduce your problems and therefore cannot try to fix it. On top of the page you find the infos I need from you. Thanks, Cacycle (talk) 20:17, 12 August 2012 (UTC)

URLs with whitespaces don't open correctly

When a user added a link in an article containing a whitespace (%20) those links can't be open properly from the diff-window, because WikEd replaces them with underscores "_".

Steps to reproduce: login on Wikipedia, enable WikEd and try to open the link in the following change: http://de.wikipedia.org/w/index.php?title=Iran&diff=105408401&oldid=105314771 It will say: File not found. Entering the link manually will work. --Incarus (talk) 21:51, 10 July 2012 (UTC)

Can I get feedback on that? Would be very important for me. --Incarus (talk) 21:48, 19 July 2012 (UTC)

Next on the list... Cacycle (talk) 20:30, 5 August 2012 (UTC)

Fixed in 0.9.104a. Cacycle (talk) 20:44, 6 August 2012 (UTC)

Thanks. --Incarus (talk) 16:50, 13 August 2012 (UTC)

Regular Javascript functions not working

For some reason, the regular editing menu and the "Insert" menu below the edit box don't work when I have wikEd enabled. I have tried this with several different browsers. --Eastlaw ^talk ⁄ _contribs 01:12, 11 July 2012 (UTC)

The last couple of days I have seen the same thing with "Insert", or maybe it is just coincidentally similar. Firefox 9.0.1 under Windows Vista Home Premium. If I click to move the insertion point, characters from the "Insert" menu do not appear, and the toggle between upper case and lower case has no effect. If I select one or more characters, then the "Insert" works, and the upper-lower case toggle works. Oh, wow, just noticed the same thing with italics and bolding. Chris the speller ^yack 03:21, 11 July 2012 (UTC)

Fixed in 0.9.103d. Cacycle (talk) 21:42, 11 July 2012 (UTC)

Yes, indeed. Thanks. Chris the speller ^yack 02:06, 12 July 2012 (UTC)

Thanks dude! --Eastlaw ^talk ⁄ _contribs 06:02, 13 July 2012 (UTC)

Cross-site scripting

In April I sent you two emails about a security issue with wikEd. Did you get these emails or should I send them again? --Schnark (talk) 10:11, 13 July 2012 (UTC)

Hi Schnark, I will fix these issues in the next release. Chris Steipp has provided a possible solution. Cacycle (talk) 17:14, 14 July 2012 (UTC)

Fixed in 0.9.104. Thanks for your patience... Cacycle (talk) 20:29, 5 August 2012 (UTC)

Black and bolded highlighting of text selection

Hi: Highlighted text in the edit area is now bolded and black, rather than the (Mac OS X) system highlight color.

See the following screenshot "side-by-side" demo available here:

https://www.dropbox.com/sh/mnbl5z8ki7jgwqn/-h6WJWyFMw/wikEdHiliteBug.jpg

The bug appears in Safari and Chrome as well.

---Schweiwikist (talk) 17:38, 17 July 2012 (UTC)

It is a browser bug, please see Firefox bug 721750 and feel free to help/comment. Cacycle (talk) 20:50, 17 July 2012 (UTC)

Thanks, however, as I previously mentioned, the bug appears in Safari & Chrome as well. Toggle wikEd text area off in any of the 3 browsers,
and my edit-area text highlighting is my preferred color. Fresh link below shows (Chrome) that the highlighting is “boxed in” after a select-all or drag-select:

http://dl.dropbox.com/u/89289597/wikEdHiliteBug02.jpg

---Schweiwikist (talk) 07:25, 28 July 2012 (UTC)

Idea (See and edit tables as tables)

I had an idea recently, and I was wondering how hard it would be to have a button in wikiEd that would display tables as actual tables, so that people could edit the entries easily without having to sort through the jumble of code. Is such a thing even possible? ~Adjwilley (talk) 19:16, 17 July 2012 (UTC)

Great suggestion. This is actually possible and most of the code has already been written (you can see it in the source). It is just that I am really busy IRL at the moment. Cacycle (talk) 20:53, 17 July 2012 (UTC)

Wow! That's exciting to hear. If I had any experience programming I would offer to dive in and help, but unfortunately I'm no programmer. Good luck with whatever you've got going on :-) ~Adjwilley (talk) 21:18, 17 July 2012 (UTC)

Custom configuration not working

I added the following to my common.js:

   var wikEdConfig = {};
   wikEdConfig.regExTypoFix = true;
   wikEdConfig.comboPresetOptions = {};
   wikEdConfig.comboPresetOptions.summary = [
       'Redirect to already-existing article', 'Copyedit', 'Reply', 'Linkfix', 'Fixing typos', 'Removing linkspam', 'Reverting test',
       'Reverting vandalism', 'Add relevant tags', 'Keep', 'Del', '+1'
   ];

Result: No RETF or summary changes
Errors: None
Version: 0.9.104a G
Browser: Safari Version 5.1.1 (7534.51.22)
OS: OS X 10.7.2

Note: I tried using var wikEdConfig.regExTypoFix = true; (as mentioned on the config page), but then I got an error about an extra . in the code.

TIA, Dori ☾Talk ☯ Contribs☽ 21:24, 10 August 2012 (UTC)

Hi Dori, there is nothing like a common.js user page, you have to use User:DoriSmith/vector.js instead. Cacycle (talk) 10:14, 12 August 2012 (UTC)

Huh? Special:Preferences#mw-prefsection-rendering says there is such a page... jcgoble3 (talk) 17:28, 12 August 2012 (UTC)

Oh, something new... The code from above actually works fine for me from vector.js as well as from common.js. Did you Shift-Reload after your change? Cacycle (talk) 20:13, 12 August 2012 (UTC)

Whew, that threw me off for a bit, as common.js has been working just fine for me with everything else.

Yes, I did every kind of reload I could think of, including quitting and restarting my browser—but no joy. Dori ☾Talk ☯ Contribs☽ 00:22, 13 August 2012 (UTC)

It is an issue with the order of execution. Please move the wikEd configuration out of your addOnloadHook handler. BTW, wikEd has its own loader. Cacycle (talk) 06:34, 13 August 2012 (UTC)

Okay, I moved it up, and now the summary changes work but RETF doesn't. Sounds like I have the same issue some other people have above, but I can live with this (or if you want me to debug stuff for you, just say the word). Dori ☾Talk ☯ Contribs☽ 08:14, 13 August 2012 (UTC)

RETF works fine for me (with the exception of the first rule as I just noticed). Please file a bug report if you have any other problems with it. Cacycle (talk) 19:54, 13 August 2012 (UTC)

My talk page

wikEd version: 0.9.104a G (August 6, 2012) browser id: Firefox 14.0.1 for Ubuntu (however the problem is also there in Chrome) Errors: Timestamp: 12-08-16 09:03:40 AM Error: TypeError: mw.loader.implement is not a function Source File: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.Experiments.experiments%2Clib%7Cext.UserBuckets%2CmarkAsHelpful%7Cext.articleFeedback.startup%7Cext.gadget.HotCat%2CNavigation_popups%2CNewDiff%2CReferenceTooltips%2CTwinkle%2CUTCLiveClock%2Cdropdown-menus%2Cpurgetab%2Cteahouse%7Cjquery.async%2CautoEllipsis%2CcheckboxShiftClick%2CclickTracking%2CcollapsibleTabs%2CdelayedBind%2ChighlightText%2Cjson%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%2CtabIndex%2Ctipsy%7Cmediawiki.Title%2Capi%2Cuser%7Cmediawiki.api.watch%7Cmediawiki.legacy.mwsuggest%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax&skin=vector&version=20120816T022829Z&* Line: 12

Timestamp: 12-08-16 09:03:41 AM Error: TypeError: c1 is null Source File: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=user&only=scripts&skin=vector&user=CambridgeBayWeather&version=20110601T005718Z&* Line: 15

Timestamp: 12-08-16 09:03:43 AM Error: TypeError: parseObj.tree[openNodeIndex] is undefined Source File: http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Line: 11802

Timestamp: 12-08-16 09:03:43 AM Error: TypeError: mw.user.sessionId is not a function Source File: http://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript&493031562 Line: 1162

Timestamp: 12-08-16 09:03:43 AM Error: TelemetryStopwatch: key "FX_SESSION_RESTORE_COLLECT_DATA_MS" was already initialized Source File: resource://gre/modules/TelemetryStopwatch.jsm Line: 53

Timestamp: 12-08-16 09:04:39 AM Error: TelemetryStopwatch: key "FX_SESSION_RESTORE_COLLECT_DATA_MS" was already initialized Source File: resource://gre/modules/TelemetryStopwatch.jsm Line: 53

Timestamp: 12-08-16 09:05:30 AM Error: TelemetryStopwatch: key "FX_SESSION_RESTORE_COLLECT_DATA_MS" was already initialized Source File: resource://gre/modules/TelemetryStopwatch.jsm Line: 53

Skin: Vector

OS: Ubuntu 12.04 LTS

Problem: When I try and edit my own talk page, User talk:CambridgeBayWeather, all I get is blank page. This does not appear to happen with any other page. However at one time it did the same thing with {{Infobox airport}} but it currently works fine there. See also Wikipedia:Help desk#My talk page. Thanks. CambridgeBayWeather (talk) 15:18, 16 August 2012 (UTC)

A few additional details (not sure if they'll help, but can't hurt): If I load you talk page with the wikEd text area turned off (as I normally do), it comes up fine. When I try to turn on the wikEd text area, the mouse cursor changes to the "busy" symbol and won't change back, and this error is produced:

• Timestamp: 8/16/2012 11:56:04 AM
• Error: TypeError: parseObj.tree[openNodeIndex] is undefined
• Source File: http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript
• Line: 11802

If I click on the wikEd text area button again, the mouse cursor goes back to normal and the edit box is now blank. Loading your talk page with the wikEd text area turned on produces a blank edit box and the same error. I get no other errors in my error console. I'm on Firefox 14.0.1, Windows Vista, Vector skin, wikEd 0.9.104a G (August 6, 2012). jcgoble3 (talk) 16:01, 16 August 2012 (UTC)

wikEd adds too much whitespace

I would like to put a word in for removing the wikEd feature that automatically adds whitespace. I tend to put exactly how much whitespace I want and need in articles and talk page comments, but wikEd insists I need more. A common example of this is where I respond to a bulleted comment as below:

• Comment 1.
  • Comment 2.

In order for this to appear correctly, there must be no line break or whitespace between the two comments. Otherwise, you get the following:

• Comment 1.

• • Comment 2.

WikEd does not seem to recognize that, and so when I intentionally omit line breaks after bulleted items, it'll add them and mess up the formatting.

On other occasions, it will inexplicably just add another line break (or sometimes two!) to a line break I already have. An example of this, compounded by a mistaken notice of an edit conflict mind you, is here. Long story short, I have never -- seriously never -- benefited from this feature. Instead, there have been a number of highly annoying occasions where I then have to go line by line removing line breaks I never inserted in the first place. Can this feature be removed, or at least include an option for it to be disabled? It seems as if some people have complained about this before, but the fact that this still has not been rectified suggests that not enough people have voiced their opinion about this.

P.S. In the course of writing this comment, the previous bug I mentioned -- whereby upon previewing or saving, all the content I wrote is gone -- just occurred. Copying the old text and pasting it in the box repeatedly did not work (saving kept producing an empty edit box), and the only way I could get this comment to post is by disabling wikEd. Sigh... I really love this gadget, but it's increasingly becoming a hinderance to my editing abilities. -- tariqabjotu 01:42, 24 August 2012 (UTC)

• It's a bug, not a feature. Please could you provide a full error description (see top of the page) so that I can try to replicate and fix this? Thanks in advance, Cacycle (talk) 15:18, 25 August 2012 (UTC)

Alright, here's the info you need:

• WikEd version: 0.9.104g
• Browser ID: Chrome v. 21.0.1180.89
• Error console errors: I don't know what you're talking about here
• Add ons: EXIF Viewer, RoxioNow Player Extension, Unfriend Finder, Zotero Connector
• Skin: Vector
• Beta Interface?: No
• Operating System: Mac OS 10.6.8

This is also relevant to the issue noted a couple sections above (and corroborated by other people) with the content I've written not showing up in previews. With both issues, there's really no rhyme or reason to it. However, with this issue (where extra whitespace comes about), it seems to consistently happen when you copy and paste content (even if it's from another open edit window and even when using CMND+Shift+V, rather than the standard paste). It'll often add whitespaces were none were desired or needed (e.g. between bullet points) or take existing whitespace and double or triple (or quadruple) it. For example, there would originally be an empty line between two paragraphs, and then after previewing or saving there are three four line breaks. This occurs in the example I noted.

P.S. Note that the preview bug occurred again while writing this comment. Luckily, I copied what I wrote to my clipboard before hitting "Preview"; this has become standard practice for me. Then, when I pasted what I copied in the window and then hit preview, I got this. -- tariqabjotu 02:33, 1 September 2012 (UTC)

WikEd does not save changes when clicking save page (~20% of time).

Instead, there is a long loading time, you are returned to the page you tried to edit, and there is no sign of your edits. Sometimes when you press the browsers back button the edit can be recovered and the save reattempted, but other times the edit is gone and you have to start again. Looks like a very nice gadget, I just can't use it due to the frustration it causes me =(

Other details: browser: chrome. I messed with my wikipedia preferences and gadgets before enabling WikEd, so maybe this combination of settings is interfering with the editor?

Not sure if anyone else reported this bug, can't be bothered to go thru archives, sorry) tepi (talk) 10:46, 27 August 2012 (UTC)

Just realized "Disable browser page caching" was enabled (don't know why) I will try again with caching disabled. doesn't explain extended loading time though... tepi (talk) 11:12, 27 August 2012 (UTC)

I don't know, but based on the reports, the common link seems to be Chrome. But surely, especially with this being Wikipedia, Chrome is widely used. Perhaps most experiencing this issue aren't reporting it (likely). -- tariqabjotu 02:37, 1 September 2012 (UTC)