Title text longer than a certain amount will not show in Element Properties dialog box

Created an attachment (id=242315)
Proposed patch for metaData.xul

The multiline attribute of the textbox elements in metaData.xul is not set, and defaults to false. As a result, the contents of the textboxes are restricted to one line only.[1]

The attached patch fixes this by setting the multiline attribute to true. I've only set it on textboxes whose contents actually seem likely to contain long strings - e.g. the URL info, the alt and title attributes, table summaries, and a few others. With the multiline attributes set to true, the text wraps normally; if it's too long for the available vertical space within the dialog, it gets a vertical scroll bar so that the user can access the remainder of the text without resizing the dialog box.

One potential issue is that in long strings with no convenient place for a text break (that means long URLs), the textbox sprouts a horizontal scroll bar. This enables the user to scroll back and forth and view the text. However, the vertical space needed for the horizontal scroll bar is reserved even when the scrollbar itself does not need to appear. That introduces a line of horizontal whitespace which looks a bit odd when there's no scroll bar there. I'll attach a screenshot demonstrating this effect shortly. I'm not sure whether it's possible to suppress the reservation of scroll-bar-space. Suggestions?

[1] For further info on the XUL textbox element and the multiline attribute, see: http://www.xulplanet.com/references/elemref/ref_textbox.html#attr_multiline

Created an attachment (id=242316)
Screenshot: the new Element Properties dialog, no scrollbars

This test was done using a page from the web comic Dr. McNinja.[1] The URL is short, and has no need to wrap; however, note that there is whitespace (errr, greyspace) underneath the URL anyway. The long title text wraps nicely.

[1] http://drmcninja.com/page.php?pageNum=14&issue=4

Created an attachment (id=242317)
Screenshot: the new Element Properties dialog, WITH scrollbars

Created using the same test page as previous screenshot; dialog has been resized to show scrollbars on both axes.

Will, you should request review from someone on the patch. Gavin Sharp (gavin.sharp@g) would be appropriate. Also, you should use a unified diff (-u).

Created an attachment (id=242389)
Revised patch (diff now made with -u switch)

Hmm. Thought I had specified -u. Guess not -- oh well, that's easily fixed. New attachment.

I've requested review now, I think. Haven't done this before - just select the ? option next to review and type in my name, right?

Still waiting for review on my patch; just a reminder.

(In reply to comment #6)
> Still waiting for review on my patch; just a reminder.

I apologize for the delay, Will.

The horizontal scrollbar in your 2nd screenshot is pretty overbearing. I wonder if we would be better off changing this dialog to use <description> elements, which has the effect of making the dialog wider if needed instead of using scrollbars. That still wouldn't handle the case of extremely long titles, though, which could potentially make the dialog as wide as the screen and still show text cut off. What do you think?

(In reply to comment #7)

> The horizontal scrollbar in your 2nd screenshot is pretty overbearing.

Yeah, it's ugly. I personally don't mind it, but it's not going to win any beauty prizes.

I'd be happier with it if it only showed up when necessary, rather than reserving space for itself even when it's not necessary. The horizonal scrollbar for the main viewport only appears when it's actually needed; it would be better if this would behave like that.

> titles, though, which could potentially make the dialog as wide as the screen
> and still show text cut off. What do you think?

> <description> still wouldn't handle the case of extremely long titles, though,
> which could potentially make the dialog as wide as the screen and still show
> text cut off. What do you think?

The problem arises from two considerations:

1) We've got more data to display than will fit in the dialog's width, or even the screen width in some cases.

2) The data doesn't offer a place to break.

The second consideration is only a problem with URLs. The alt and title attributes typically contain standard written words, with ample spaces for wrapping the text. Any web site that uses alt and title text with NO spaces in it is probably trying something fishy anyway. So, for alt, title, and basically all the non-URL fields, we can go ahead and just use the multiline attribute as in this patch.

As for the URLs, there's the real problem. And you're right, the <description> element isn't a real fix. The initial reporter was able to demonstrate an URL so large that it was too large for the whole screen, particularly at low screen resolutions. Description just automates the process of widening the dialog, which is itself not exactly a pretty effect. Nobody expects to have a dialog pop up that's as wide as the whole screen.

I just did some experimenting; apparently, it is possible to select the text on the properties dialog. If you select all the way to the right edge of a truncated string, the selection will keep going, revealing the truncated info. The string slides to the left, marquee style. So it IS possible to get the info, by scrolling back and forth while selecting the text. But it's awkward, and there's no indication in the UI that it's possible. Hence this bug report.

Another possibility might be to alter the connected JavaScript to insert artificial "breaks" after a certain number of characters. Say, 40? But that makes it harder for the user to select the URL for copying, since it's on multiple lines. Also, it could lead to typographic orphans. Suppose you have an URL that's 41 characters long, and the last character is the L in ".html". The JS breaks at 40, and that final "L" moves down to the next line, all the way at the left. The viewer will see that the URL ends in ".htm" (which some pages do), and get confused if they try copying and pasting. (I'm inclined to think, though, that very few users will actually want to copy and paste the URL from this dialog. There's an easier way to get it: right-click the link and select "Copy Link Location.")

I have to say, the horizontal scrollbar may actually be exactly what we need. The sole purpose...

(In reply to comment #8)
> (In reply to comment #7)
>
> > The horizontal scrollbar in your 2nd screenshot is pretty overbearing.
>
> Yeah, it's ugly. I personally don't mind it, but it's not going to win any
> beauty prizes.
>

This seems far too ugly to me, can we not default the textbox to 2 lines? This would leave a much smaller white space on short urls but when you stretch the box full screen width on long urls you should be able to view 99.9% of them.

(In reply to comment #9)

> This seems far too ugly to me, can we not default the textbox to 2 lines? This
> would leave a much smaller white space on short urls but when you stretch the
> box full screen width on long urls you should be able to view 99.9% of them.

That won't help. The availability of vertical space (ie lines) is not the problem. The problem is that there is no white space in the URL where it can wrap to a second line.

Just for kicks, I just created a version of metaData.xul with this line:

<textbox readonly="true" rows="2" id="link-url-text"/>

Then I created a link with a really long URL and took a look. There was no ugly whitespace under the link text, but the URL was still cut off, because it didn't wrap. (See screenshot: 2 rows.)

I also created a version using a DESCRIPTION element instead of a TEXTBOX element. (See screenshot: description.) It makes the dialog's width vary according to the URL's width, but still doesn't solve the problem of chopped-off-chunks in really long ones.

I think I've figured out how to handle this. What we need to do is alter the JavaScript that populates the dialog so that it checks the length of the string. In the event of a string longer than, say, 25 characters, then the script can set the MULTILINE attribute to true for that particular textbox. Otherwise, we'll leave it false. That will make the data available for long URLs, but prevent the extra ugly whitespace from showing up in short URLs. Unfortunately, the JavaScript for this is considerably more complicated than the XUL. I'll have to study it for a while to figure out what it does and how.

Created an attachment (id=244363)
2 rows

Created an attachment (id=244364)
Using description element instead of textbox

Created an attachment (id=244634)
Checks length of string value and sets multiline attib if needed

Okay, I've spent some time wading through the JavaScript in metaData.js. Here's a new patch, invalidating the old. Instead of setting the multiline attribute manually in metaData.xul, this one sets the attribute conditionally. If the value to be inserted is longer than 55 characters, then the JS sets the appropriate node in the XUL to multiline="true".

Advantages:
- Long text in alt/description/etc wraps.
- Long URLs with no good break-point get a horizontal scroll bar.
- No ugly white-space issue with shorter URLs.

However, it's not perfect. 55 characters is an estimate. I just found a long string and counted how many characters before it wrapped (58) and then tweaked it down a little bit to be on the conservative side. But the font is proportional - not all the characters are the same width. So in some rare cases right on the border, there may be elements that get a multiline setting but don't need it, and vice versa. In order to be perfect, I would need to figure out some way of determining whether a particular string is long enough to need wrapping, and I don't know any good way to do that.

I think that's a really minor issue, though. For the vast majority of cases, this should do it.

(In reply to comment #13)
> Created an attachment (id=244634) [edit]

Will, the comment in the patch says 25 char?

I still don't like the scroll bar, is there not a way to conditionally add a line break into the string to make it wrap?

Created an attachment (id=244763)
Now with line breaks

Fine!

Changelog:

- Added code to insert line breaks into strings that do not contain any spaces (line breaks make it easier to re-assemble the URL properly if the user copies and pastes it).

- Reduced the length limit to 35 characters; this is because the dialog is narrower when the target element is a link and nothing else. With 55, long URLs were breaking to multiple lines but STILL had a horizontal scrollbar.

- Changed the number in the comment to match the code.

*** Bug 365610 has been marked as a duplicate of this bug. ***

Is bug 346650 a dup?

Yes.

And could someone please review the code I wrote? It's been ages.

*** Bug 346650 has been marked as a duplicate of this bug. ***

(From update of attachment 244763)
I don't like hardcoding limits like "35" into the code like this, since it's unlikely to be correct for various resolutions/dialog sizes etc. I also don't like playing with the source string and adding newlines. I'm not sure what the best way to solve this is, but I don't think this solution's cost/benefit ratio is low enough.

On the resolution/dialog size issue - fair enough. I've never liked the hard-coding thing either. I'm not sure I understand the objection to inserting newlines, though.

Having reviewed our progress thus far, it seems to me that we're working on two distinct issues:

1) Wrapping URLs. (link-url, image-url)
2) Wrapping everything else. (image-alt, image-desc, insdel-cite, quote-cite, misc-title, misc-tblsummary)

The URLs are the hard part, because they don't have any natural breaks in them. The others are all easy, because they do. For everything EXCEPT urls, it's a simple matter of setting the multi-line attribute on the textbox elements.

I therefore have a proposal: let's fix the plain text ones and file a new bug for the URLs. That way the alt/title/cite/summary stuff that people might actually want to read can be read without fiddling with the dialog size, and we can work on the URL issue separately. Half a bug squashed is better than no bug squashed.

*** Bug 390917 has been marked as a duplicate of this bug. ***

This UI was removed (bug 513147).