Closed Bug 1389111 Opened 2 years ago Closed 2 years ago

Don't apply autosizing specific properties to comments when autosizing disabled

Categories

(bugzilla.mozilla.org :: General, defect, major)

Production
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: bzbarsky, Assigned: wlach)

References

Details

Attachments

(1 file)

PR
45 bytes, text/x-github-pull-request
dylan
: review+
Details | Review
Comment fields on bugzilla are still fixed to a too-small size that makes working with them extremely difficult.  Imagine something basic like typing https://bugzilla.mozilla.org/show_bug.cgi?id=1367854#c34 and wanting to see the whole table at once (something I'm in the middle of trying to do right now)!

The pref implemented in bug 1380352 which was theoretically supposed to work around this is broken in two ways:

1)  It still starts off the comment field at a tiny height (6 rows) even in non-auto-resizing mode, pretty much guaranteeing that the user _will_ want to resize it for pretty much anything.

2)  Bugzilla is s still setting a max-height of 400px (via the rule with the "#comment, #comment-preview" selector) even if the auto-resizer is turned off.  So even manually the comment field can't be made taller than 400px, which is about 25 lines.

For comparison, the field I'm typing in right now (the one you get when initially filing the bug) has none of these problems: it starts at 10 rows, it's resizable arbitrarily tall, and is generally a much more pleasant experience.

Can we just remove the max-height style?  I just tried doing that using devtools, and even with auto-resizing mode on things seem to work great with it removed: I can resize the textarea to any size I please.  I don't have a problem with the autosizing per se, but the artificial limits on how big I can make the comment field are really frustrating.  They've been wasting a huge amount of time for me; in many cases I've had to edit my comment in an external editor just so I can see enough of it to be able to type it sanely.  :(
Flags: needinfo?(wlachance)
Wishing right now that I hadn't touched this issue with a 10-foot pole, it's definitely been way more trouble than it's been worth.

I'll make sure none of the autosizing-specific preferences get applied, maybe I can also fix bug 1386529 while I'm at it.
Assignee: nobody → wlachance
Flags: needinfo?(wlachance)
William, sorry about all the complaining about this.  :(

Again, the autosizing is not actually being a problem in my case; with autosizing enabled and the max-height removed things work reasonably.  For bug 1386529 you may also want to remove the max-width and "resize: vertical" styles...
(In reply to Boris Zbarsky [:bz] (vacation Aug 14-27) from comment #2)
> William, sorry about all the complaining about this.  :(
> 
> Again, the autosizing is not actually being a problem in my case; with
> autosizing enabled and the max-height removed things work reasonably.  For
> bug 1386529 you may also want to remove the max-width and "resize: vertical"
> styles...

Hmm, if autosizing is enabled then the max-height property should be removed if you manually resize. I'm not sure if that's intuitive.

In any case, creating a special "autosize comment" class with max-height/resize properties seems to work great. The max-width has always been there, so I'm going to avoid touching it in the interests of not accidentally breaking something else. :)
Attached file PR
Attachment #8895877 - Flags: review?(dylan)
Summary: Please remove the max-height style on comment fields → Don't apply autosizing specific properties to comments when autosizing disabled
Duplicate of this bug: 1386529
> Hmm, if autosizing is enabled then the max-height property should be removed if you manually resize.

Right now it's not.  Does "should" mean "it's meant to work that way right now", or "it would be good if it worked that way"?

Seriously, if we just didn't have, or removed, the max-height when doing a manual resize, that would solve the problem I'm having.  The linked PR doesn't do that.  :(  Nor does it address item 1 from comment 0, if the intent is that auto-sizing be disabled...
(In reply to Boris Zbarsky [:bz] (vacation Aug 14-27) from comment #6)
> > Hmm, if autosizing is enabled then the max-height property should be removed if you manually resize.
> 
> Right now it's not.  Does "should" mean "it's meant to work that way right
> now", or "it would be good if it worked that way"?

As in "it's meant to work that way right now". And does, afaict (just tested)? Are you sure autosizing is enabled for you?

> Nor does it address item 1 from comment 0, if the
> intent is that auto-sizing be disabled...

So I'm a bit confused about that as well. For me, if I disable autosizing and start writing a comment, it auto-resizes the comment area to something quite large (about 400px). If autosizing is enabled, yes, it starts off relatively small but will expand as you type in your comment -- we could consider expanding it a bit, otoh I don't see any big usability issue with the way it is now (I suspect you're just used to expanding a text area that small in anticipation of writing something longer?).
(In reply to William Lachance (:wlach) (use needinfo!) from comment #7)
> (In reply to Boris Zbarsky [:bz] (vacation Aug 14-27) from comment #6)
> > > Hmm, if autosizing is enabled then the max-height property should be removed if you manually resize.
> > 
> > Right now it's not.  Does "should" mean "it's meant to work that way right
> > now", or "it would be good if it worked that way"?
> 
> As in "it's meant to work that way right now". And does, afaict (just
> tested)? Are you sure autosizing is enabled for you?

Just to be clear, autosizing is only enabled if "Expand the comment box dynamically" under general preferences is set to "on". Its default mode is "off".
Funny Boris feels limited by this, too. I'm the reporter of bug 1386529 (and bug 1381200).

(In reply to Boris Zbarsky [:bz] (vacation Aug 14-27) from comment #0)
> For comparison, the field I'm typing in right now (the one you get when
> initially filing the bug) has none of these problems: it starts at 10 rows,
> it's resizable arbitrarily tall, and is generally a much more pleasant
> experience.
+1
> Are you sure autosizing is enabled for you?

Ah, we might be talking about two different things.  I have "Zoom textareas large when in use (requires JavaScript)" set to "Site Default (On)" in my preferences.  I have "Expand the comment box dynamically" also set to the site default, "Off".

I thought we were talking about the "Zoom textareas" behavior, not the "Expand the comment box dynamically" one.
(In reply to Boris Zbarsky [:bz] (vacation Aug 14-27) from comment #10)
> > Are you sure autosizing is enabled for you?
> 
> Ah, we might be talking about two different things.  I have "Zoom textareas
> large when in use (requires JavaScript)" set to "Site Default (On)" in my
> preferences.  I have "Expand the comment box dynamically" also set to the
> site default, "Off".
> 
> I thought we were talking about the "Zoom textareas" behavior, not the
> "Expand the comment box dynamically" one.

Ah ok, that makes more sense. And the attached PR should fix your issues, I think (because the offending CSS property will no longer apply to the comment box).
Attachment #8895877 - Flags: review?(dylan) → review+
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
When will that be in production? Supposedly this should fix bug 1386529, but so far, the comment box is still restricted.
Flags: needinfo?(dylan)
As soon as a push happens, yes. The code isn't commited yet due to a build stoppage because of bugs in our CI that have just been fixed.
Flags: needinfo?(dylan)
Duplicate of this bug: 1383513
You need to log in before you can comment on or make changes to this bug.