Comment 8 for bug 301054

(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 of the element properties dialog is help the user to get more detailed information about a page element. In the current version, it cuts off some of that information in some cases, which undercuts (ah ha, a pun!) its purpose. It IS possible to retrieve that information, but there's no UI cue to indicate that possibility. The scrollbar will let even a casual user know that they can slide back and forth to see the rest of the URL, and it works even if the URL is so long that it exceeds the width of the screen.

So, unless somebody can suggest a better alternative, I'd say go with the horizontal scroll bar, ugly though it may be.