biontiger.blogg.se - Textify did not succeed

TEXTIFY DID NOT SUCCEED MAC OSX
TEXTIFY DID NOT SUCCEED FULL

I can still reproduce it from steps given above). Thanks in advance, Cacycle ( talk) 04:53, 19 February 2009 (UTC) Unfortunately, the problem persists for me in 0.9.73a (i.e. Missing spellcheck is a browser problem not related to wikEd.

TEXTIFY DID NOT SUCCEED FULL

Please could you fill out the full bug report form on top of the page so that I can reproduce your problems.

NJGW ( talk) 07:08, 5 February 2009 (UTC) It works fine for me with Chrome >= 1.0.154.43 / WinXP. Incidentally, in Chrome misspelled words are only highlighted when wikEd is turned off. First it deletes the breaks, then inserts too many. This is still happening to me (Feb 4, Chrome/WinXP). Thanks, Cacycle ( talk) 03:15, 2 February 2009 (UTC) Just found this thread.

Please report back if you still experience problems related to this. GregorB ( talk) 09:36, 27 January 2009 (UTC) I have probably fixed this with browser detection in 0.9.71. This could force me back to 100% Firefox - no big deal perhaps, but still. I'm currently doing 25% of editing in Chrome, 75% in Firefox. It's probably a some sort of WebKit misfeature. I could not find this reported at - which is a bit odd, since one would expect this to hurt other rich text editors too. It seriously messes things up and there is no easy workaround for it other than using browser detection as far as I can see :-S Cacycle ( talk) 04:29, 27 January 2009 (UTC) Divs are inserted indeed this behavior can be seen at e.g. Cacycle ( talk) 02:55, 26 January 2009 (UTC) Safari and Chrome use. 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.

Problem and steps to reproduce: as described aboveĪpparently not Mac-related.

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

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

Unfortunately, it doesn't seem to me to be entirely reproducible or predictable. 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. This is not limited to pasting rich text for me.

TEXTIFY DID NOT SUCCEED MAC OSX

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). 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.

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

Thanks, Cacycle ( talk) 00:26, 19 January 2009 (UTC) Here's what "works" for me:

I could not reproduce your problem in Chrome, please provide a detailed how-to so that I can reproduce it. Push the or button to remove the original formatting of your pasted text. GregorB ( talk) 22:40, 18 January 2009 (UTC) When pasting rich text it is not always easy to see the number of line breaks. GregorB ( talk) 22:38, 18 January 2009 (UTC) Funny, it happened without a copy/paste, just as I was writing this. Do you know what might be the reason? I'm suspecting a Webkit bug. This happens in Google Chrome, never in Firefox. 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.you copy and paste something in the edit window.It appears that wikEd sometimes inserts or deletes a newline in the edit window.