WYSIWYG editor a narrow strip

Could I get a pointer for troubleshooting an instance?

A fresh install of 1.08 onto Bluehost, reconfig to Natskin, then an upgrade to 1.09

The WYSIWYG edits don't expand in width (see attached).

If I append ?skin=pattern to the URL, it renders as expected, full width, and the Full Screen button is now visible and usable.

1. Is there a point for a work around?
2. Failing that, is there a way to temporarily edit a template to append ;skin=pattern for the edit button? Disabling WYSIWYG won't be viable for this user group.

Thanks in advance.

---

I really am sorry for this bug, it was my fault. See Tasks.Item2368. distro:c3b70d86209f is the fix. I fixed a couple of days after that version of NatEditPlugin was released, but MichaelDaum is busy doing a lot of work these days improving lots of things. So until he makes a new release, please replace the following files in /pub/System/NatEditPlugin:

• http://svn.foswiki.org/trunk/NatEditPlugin/pub/System/NatEditPlugin/edit.js
• http://svn.foswiki.org/trunk/NatEditPlugin/pub/System/NatEditPlugin/edit.js.gz
• http://svn.foswiki.org/trunk/NatEditPlugin/pub/System/NatEditPlugin/edit.uncompressed.js
• http://svn.foswiki.org/trunk/NatEditPlugin/pub/System/NatEditPlugin/jquery.natedit.js.gz

Also ensure NatSkin, NatSkinPlugin and JQueryPlugin is up to date.

If you still have problems, please set this question status back to "asked"

-- PaulHarvey - 29 Jan 2010

That was my first step, should have mentioned it. Though the 3 Nat plugins reported the latest versions, I reinstalled via Configure, plus updated to the recently updated JQuery.

Plugins reported as:

• JQueryPlugin (3.01, $Rev: 20090710 (2009-07-10) $): jQuery JavaScript library for Foswiki
• NatEditPlugin (v4.20, $Rev: 5550 (2009-11-17) $): A Wikiwyg Editor
• NatSkinPlugin (3.95, $Rev: 5563 (2009-11-17) $): Theming engine for NatSkin

-- CraigBowers - 29 Jan 2010

• Which browser are you using?
• After replacing the edit*.js files with the patched version from svn,
  • Did you try both clearing your browser cache, and using shift key + refresh button to force reload?
• Can you confirm that visiting the javascript files /pub/System/NatEditPlugin/edit.js and /pub/System/NatEditPlugin/edit.uncompressed.js contains
  $(window).trigger('resize.natedit');
  as per distro:c3b70d86209f?
• What happens if you resize the browser window? Does the TinyMCE editor re-size itself properly?
• Do you have any javascript errors? In Firefox, try ctrl+shift+j to see the error log.

-- PaulHarvey - 29 Jan 2010

• Problematic browsers were Chrome and Firefox 3.5 on XP, Safari 4.04 and Firefox 3.6 on MacOS X 10.5.8
  • Clearing cache and Shift refresh, has no effect, but I'm not aware of the SVN updates you reference. For NatEditPlugin?
• Yes, you're correct that resizing the browser works (I got hung up trying to drag the corner control of the edit field box.)
• Both the JS files you mention contain "$(window).trigger('resize.natedit');" in 2 locations. The Foswikirev:5416 reference slipped over my head though. I mean the files on svn.foswiki.org/trunk, did you download them and copy to /pub/System/NatEditPlugin?
• Testing today on a 3rd box (XP) does not yield the issue though (IE8, Firefox 3.5.6, Chrome 4.0.249.78 beta 36714) !? (I have remote access to one (the Mac) of the 2 others and it still does after clearing cache and force reloading in both Safari and Firefox). Difference if Javascript handling?
• No javascript errors in either the working or non-working browser instances. Many warnings in the CSS though on both.

-- CraigBowers - 01 Feb 2010

This problem never appeared for me initially because I use portrait mode screens at work, and landscape at home.

What are the resolution and orientation of the displays in the working vs non-working setup?

If you are feeling adventurous, I have attached a version of the js files which will output to a firebug console (you must have firebug installed). These should be saved to /pub/System/NatEditPlugin/

• edit.js: edit.js
• edit.js.gz: edit.js.gz
• edit.uncompressed.js: edit.uncompressed.js

Please update with these files, run firefox with the firebug add-on installed, and tell me if you see the debug messages in the console window (share the output here)

What should happen in the firebug console:

• When you first start the editor:

  about to call resize.natedit from window.load event

• When you switch to raw and back to WYSIWYG:

  about to call resize.natedit from switchToWYSIWYG

-- PaulHarvey - 01 Feb 2010

Have not proceeded with the file replacement yet, your other hints had me poke and jab things into behavior. On re-occurence, I'll update those files though . I don't have access to the original problematic XP workstation (1680x1050).

However problematic Mac was dual display. 1024x768 (secondary - portrait mode), and 1440x900 (landscape - internal display).

The non-problematic XP client was 1024x768 landscape, and 1650x1080 landscape secondary display.

After changing the display resolution on the 1440x900 internal display to 1024x768, the text area snapped to the browser width. Returning the display resolution to 1440x900 kept the proper behavior.

No amount of cajoling, relaunching, reloading seems to be able to reproduce the original failure of the text area to expand now on edit.

Unless the above test info would be useful to you, I'll hold off further on this for now.