You are here: Foswiki>Tasks Web>Item12607 (19 Nov 2013, GeorgeClark)Edit Attach

Item12607: EDITBOXHEIGHT cookie considered harmful

Priority: Normal
Current State: Closed
Released In: 1.1.9
Target Release: n/a
Applies To: Engine
Component: FoswikiUIEdit
Branches: Release01x01 trunk
Reported By: JohnHenning
Waiting For:
Last Change By: GeorgeClark
At foswiki_edit_src.js line 94, it is commented that changes to EDITBOXHEIGHT are saved to a cookie.

These changes come from the up/down arrows that appear just below the edit box, as shown in attachment: updown.png

The cookie creates two problems:
  • (1) it breaks multiple examples and doc pages
  • (2) it causes great user annoyance

(1) Broken docs

There are many   documentation   pages   and   support   pages that either define EDITBOXHEIGHT or use it as an example along the way to defining some other feature. The pages linked in this sentence are by no means claimed to be exhaustive. It does not appear that any of them mention that "oh by the way, the stuff you enter may be silently ignored if you have ever touched the little arrows below the edit box."

In particular, please note that this diagram from becomes incorrect, or at least incomplete, if the user has ever touched the little arrows:


(2) Confused and annoyed users

This user was led down a merry chase:
  • Why is my preference ignored? Is it the recent change to the foswiki version on our server?
  • Some preference set at another level?
  • Some mistake in how I typed it?
  • Some reason why my page is too complex, breaking something else? Simplify my page!
  • Nope, that's not it. Ah, here is a macro to print out all site preferences and user preferences. Nope, no clue
  • No, wait, look at the HTML source. It plainly says:
    textarea class="foswikiTextarea [...snip...] id="topic" name="text" rows="55"
  • Hmmm, it seems to be related to my browser! But why would it work for Firefox and not Safari? Why would Safari get it wrong if it was told 55?
  • OK, set a breakpoint in the javascript, which led to the comment mentioned at the top of this description

About frequency of annoyance -

Please note that this user happened to be vaguely familiar with the tool chain, and has been described as stubborn/persistent. That eventually led me to the cookie that I need to delete; but I suggest that most users may not be as persistent.

There are likely many users who have been annoyed that a feature mentioned so often in the documentation is broken, but they have not bothered to root cause it.

-- JohnHenning - 21 Oct 2013

Unfortunately work for 1.2.0 slipped into 1.1. 1.2 will remove these settings when Foswiki converts to the NatEditPlugin as the default editor.

We'll correct the documentation for 1.1.9.

Other than the unfortunate confusion with the preference setting, is there a reason that 1.2 shouldn't remove this setting, using the cookie method exclusively.

This new cookie was part of the javascript changes made in FoswikiRelease01x01x00

-- GeorgeClark - 21 Oct 2013

George, thank you for the timely response. Two responses.

First, as to doc fix - I suggest that EDITBOXHEIGHT is so widespread through the documentation, and is so ANCIENT in user habit, that a simple doc correction is unlikely to reach the needed places. Perhaps some better options might include:

  • (1a) Add tiny print under arrows "over-rides EDITBOXHEIGHT"

  • (1b) Notice whether the user has set a preference on their page. If so, take that as the user caring enough to express an opinion, and therefore:
    • (1b1) don't save a cookie, or
    • (1b2) make the cookie temporary to this session, or
    • (1b3) re-write user page to match the cookie, or
    • (1b4) change user page "* Set EDITBOXHEIGHT" to "*# Set EDITBOXHEIGHT"

  • (1c) If saving user page, and it includes an EDITBOXHEIGHT that differs from cookie, then change cookie to match setting.

RECOMMENDATION: do both (1b4) and (1c)
  • Justification for (1b4): it is, effectively, what you are doing smile
  • Justification for (1c):
    • It recognizes that someone has taken the trouble to say what s/he wants, via the documented and ancient method, and it honors what is said.
    • It would have saved this user oodles of time, and avoids other users going down similar wrong-paths

Second, you ask about getting rid of the preference entirely, using only the cookie method. Three things to note about that:
  • (2a) There is a UI cost from breaking user habit, ancient knowledge; perhaps worth it, but must be factored in
  • (2b) For this user, personally: what I like about the preference is that I can rapidly change from 22 lines (suitable for tiny laptop) to 114 lines (my usual setting, when laptop has 2x external monitors, both rotated 90 degrees to 1080x1920). Changing 22 to 114 feels faster than plunking on the down arrow 30 times.
  • (2c) Related question: will it save my preference if I adjust vertical rows by grabbing the corner? See attachment:


The current behavior with Foswiki-1.1.5 (*), Safari 6.0.5, Mac OS X 10.8.5 is that the arrows cause cookies, but the corner grab does not; furthermore, I can only make it bigger with a corner grab, and cannot make it smaller.

(*) hmmm, i thought I saw 1.1.8 yesterday, but I guess I was mistaken. Changing the checkbox below to 1.1.5.

-- JohnHenning - 22 Oct 2013

I've done a bit of digging with the upcoming 1.1.9
  • Dragging the corner of the text edit window does not update the cookie
  • Dragging the corner of the TinyMCE window does not update the cookie
  • The arrow and font buttons set the cookie.

-- GeorgeClark - 23 Oct 2013

Let's remove these buttons.

-- MichaelDaum - 23 Oct 2013

I'll close this as a documentation change to 1.1.9. I'll open a task against 1.2 to rationalize the buttons / cookie / EDIT* settings / corner drag operations.

-- GeorgeClark - 03 Nov 2013

Item12628 opened urgent agains 1.2.0.

-- GeorgeClark - 03 Nov 2013

George, which 1.2.x features did you see leaking into the 1.1.x branch? Note that the grab-corner at the bottom is merely a feature of modern browsers and not implemented by foswiki.

-- MichaelDaum - 03 Nov 2013

Michael, It was the deprecation of EDITBOXHEIGHT by NatEditPlugin. IIRC, 1.2 deprecates them ... well, it disables them, as there was no formal deprecation period. In 1.1 they are not actually deprecated, but instead the cookie overrides it, and that's purely 1.1.x, and it was not documented. It will be documented for 1.1.9 at least a bit better.

Anyway I took this task to annouce the deprecation (elimination?). of these settings in 1.2, as part of 1.1.9.

-- GeorgeClark - 04 Nov 2013

ItemTemplate edit

Summary EDITBOXHEIGHT cookie considered harmful
ReportedBy JohnHenning
Codebase 1.1.8, 1.1.7, 1.1.6, 1.1.5
SVN Range
AppliesTo Engine
Component FoswikiUIEdit
Priority Normal
CurrentState Closed
Checkins distro:768377d2310c distro:4bb3a14052dd
TargetRelease n/a
ReleasedIn 1.1.9
CheckinsOnBranches Release01x01 trunk
trunkCheckins distro:4bb3a14052dd
Release01x01Checkins distro:768377d2310c
Topic attachments
I Attachment Action Size Date Who Comment
grabCorner.pngpng grabCorner.png manage 7 K 22 Oct 2013 - 11:21 JohnHenning  
updown.pngpng updown.png manage 11 K 21 Oct 2013 - 15:33 JohnHenning  
Topic revision: r11 - 19 Nov 2013, GeorgeClark - This page was cached on 15 Jan 2020 - 00:56.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy