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
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:
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
http://foswiki.org/System/PreferenceSettings 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
- 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