Opened 12 years ago

Closed 8 years ago

#314 closed defect (fixed)

status bar should wrap in firefox

Reported by: white@… Owned by: gogo
Priority: normal Milestone: 0.96
Component: Xinha Core Version: trunk
Severity: normal Keywords: status bar wrap
Cc:

Description

If the status bar is displaying a long line of information (for example, when I right-click on a very long link and mouse-over the "Modify Link" option in the context menu), then the line doesn't wrap, but forces xinha to expand to the size of the line of text. This only seems to happen in firefox, not ie.

Attachments (4)

ffnormal.jpg (44.2 KB) - added by jkronika@… 12 years ago.
Firefox 1.0.4 - Status Bar Normal
ffexpand.jpg (56.3 KB) - added by jkronika@… 12 years ago.
Firefox 1.0.4 - Expanded
ieexpand.jpg (63.7 KB) - added by jkronika@… 12 years ago.
IE 6 - Expanded
iewhitespace.jpg (52.6 KB) - added by jkronika@… 12 years ago.
IE 6 - Whitespace after Expansion

Download all attachments as: .zip

Change History (9)

comment:1 Changed 12 years ago by jkronika@…

Another problem, in the same situation, crops up in IE, where the status bar wraps as would be expected and/or desired, but when the message becomes short enough to no longer require wrapping, there becomes a white space below the status bar equivalent to the extra height added when the message was wrapped. I will attach screenshots for both situations.

Changed 12 years ago by jkronika@…

Firefox 1.0.4 - Status Bar Normal

Changed 12 years ago by jkronika@…

Firefox 1.0.4 - Expanded

Changed 12 years ago by jkronika@…

IE 6 - Expanded

Changed 12 years ago by jkronika@…

IE 6 - Whitespace after Expansion

comment:2 Changed 12 years ago by Artus

It's certainly not the best thing to do, but I added the line:

  statusbar.style.overflow = "hidden";

to _createStatusBar. This seems to prevent the resizing in Firfox, but the line isn't broken, but cut off. Is there a way, to force Firefox to break in a long string?

comment:3 Changed 9 years ago by ray

  • Milestone set to 0.96

comment:4 Changed 8 years ago by nicholasbs

I don't think there's any way to force FF to wrap in this case. We could do some string processing in JS and come up with heuristics for how to break it up, but that seems like it'd become hacky and ugly pretty quickly.

The above suggestion of setting the overflow of the status bar to "hidden" doesn't work in either FF2 or FF3 unless you explicitly set the width. This is easy enough to do by registering functions with notifyOn() for resize and before_resize (you have to set width to null on before_resize otherwise the actual editor resizing doesn't work properly).

Doing the above works in all the browsers I've tested (FF3, Safari 3 and IE7), but problems arise when plugins insert their own content in the status bar. This is currently only an issue with the CharCounter plugin, which inserts itself after the status bar tree info. IMHO, this is a consequence of plugins modifying Xinha in an ad hoc fashion; it seems to me that if we want to allow plugins to add elements to the status bar, we should expose an interface for doing so.

So, should we 1) come up with some sort of interface for putting stuff in the status bar; 2) just fix things for CharCounter, since it's the only plugin actually doing this in a problematic way; or 3) do something entirely different.

Thoughts?

comment:5 Changed 8 years ago by nicholasbs

  • Resolution set to fixed
  • Status changed from new to closed

Changeset r1142 fixes this problem by following path (1) listed above, i.e., turning on overflow, dynamically setting a fixed pixel width, and creating an interface by which plugins can register status bar widgets. The changeset includes updates for CharCounter as well as minor CSS tweaks for the various Xinha skins.

This code has been tested and works in FF2, FF3, Safari 3 (Mac), and IE 7. It works in IE 6 with the exception that the status bar is a couple of pixels too wide (will look into shortly).

Note: See TracTickets for help on using tickets.