Closed Bug 91662 Opened 24 years ago Closed 21 years ago

Long Strings in Mail/News Header causes Folder Pane to Resize and/or Jiggle

Categories

(SeaMonkey :: MailNews: Message Display, defect, P2)

x86
Other
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 247833
mozilla1.2alpha

People

(Reporter: sspitzer, Assigned: BenB)

References

()

Details

(Keywords: dataloss, Whiteboard: [ADT3])

Attachments

(17 files, 21 obsolete files)

1.86 KB, text/plain
Details
20.38 KB, application/octet-stream
Details
4.10 KB, patch
Details | Diff | Splinter Review
32.13 KB, image/png
Details
45.32 KB, image/jpeg
Details
18.24 KB, image/png
Details
279.78 KB, image/jpeg
Details
158.24 KB, image/jpeg
Details
155.48 KB, image/jpeg
Details
83.97 KB, image/png
Details
5.34 KB, text/plain
Details
59.69 KB, image/gif
Details
1.62 KB, application/octet-stream
Details
51.67 KB, image/jpeg
Details
9.10 KB, image/png
Details
9.10 KB, image/png
Details
4.62 KB, patch
Details | Diff | Splinter Review
emails with long subjects make thread pane go wild sample message coming up.
note, it wasn't until I loaded the message that the thread pane went wild.
updating summary. I'm not sure yet if it is long subjects, that particular subject, or what. my guess it is an outliner bug, but I'll investigate first.
Status: NEW → ASSIGNED
Summary: emails with long subjects make thread pane go wild → emails with long subjects make thread pane go wild once the message is loaded
*** Bug 91229 has been marked as a duplicate of this bug. ***
There are a few older bugs about this, I'll duplicate them to this one since Seth is working on it... 83503 85106 76793
*** Bug 85106 has been marked as a duplicate of this bug. ***
*** Bug 76793 has been marked as a duplicate of this bug. ***
so when the email with a long subject is selected, this happens. if it isn't selected, this doesn't happen. the place to start is the outliner code that paints the text (or images) and checks if the row is selected or not.
Note that long "to" fields also break. (see duplicate Bug 85106) I see what's happening. The culprit here is the message pane's toolbar. Long subjects normally wrap at the right edge of the window. If the subject contains no whitespace (or contains an extremely long word) then Mozilla behaves as if its right edge was actually at the right edge of this extremely long string except that it doesn't go to the trouble of resizing the window. In the test case that I am about to attach notice that: - the throbber disappears - the stuff in the right side of the status bar disapears (eg. Unread: Total) - on a high res screen not all the fields disappear unless you resize the window to be pretty small. If you widen up the window all the way, the entire subject can display and everything looks normal. - the paragraph wraps at the end of the subject line. If the entire subject isn't displayed then the right end of the paragraph is also truncated. - as you widen the window the content of the status bar and the throbber slowly return to view from the right.
Attached file better test case
isn't this just a missing crop="right" attribute?
it seems like crop="right" will crop the subject even if it has normal whitespace and can wrap properly. Doing that would be fairly suboptimal, although its probably better than making the thread pane unusable. rob says that in chatzilla he adds 0px images to long strings to make them wrappable.
I think bug 83503 is a dup.
*** Bug 83503 has been marked as a duplicate of this bug. ***
As noted in bug 83503, long cc: addresses (with or without spaces) also make this show up. It's especially annoying if the message has file attachments because the whole attachment list falls off the right side of the window.
Erich has a good point. This bug also make the scrollbar in the message pane go away. My test case isn't long enough to demonstrate that. Between missing scroll bars and missing attachment windows this bug makes mozilla quite unusable for certain messages. It seems like some people with low res screens could find this happening with most or all of their mail. Adding dataloss keyword. This bug occurs with both modern and classic.
Keywords: dataloss
stepping through nsOutlinerBodyFrame.cpp, we are cropping right. if you don't define a crop style, we crop right. you can tell we are cropping because in most cases "..." is appended to the end of large text cells. it's just these monster subjects that are horking us. I'm back in the debugger, trying to figure it out.
interesting: if I collapse the message pane, selecting the "evil" message doesn't cause the thread pane to go wild.
this sounds wacky, but I think it has something to do with the subject in the message pane. If I toggle to the collapsed view (in the message pane) it doesn't happen either.
I'm guessing that the two share a box, and so when the subject in the message pane gets huge, it stretches the box associated with the thread pane. getting close here...
Summary: emails with long subjects make thread pane go wild once the message is loaded → emails with long subjects make thread pane go wild, if message pane is visible and you are not in "collapsed" header view.
Summary: emails with long subjects make thread pane go wild, if message pane is visible and you are not in "collapsed" header view. → emails with long subjects make it impossible to see the attachment tree and make thread pane go wild, if message pane is visible and you are not in "collapsed" header view.
taking with mscott, this is not the right fix. we use an <html> tag and flex=1 so that large subjects will wrap. for wrapping to occur, there needs to be spaces in the subject. by removing flex=1, I've made it so subjects with spaces won't wrap, which is bad. so there are two parts of this bug. 1) make it so long subjects without spaces don't make the thread pane go wild 2) make it so long subjects without spaces don't push the attachment tree off screen.
Don't forget, long email addresses in the message header cause the same problem. If you consider that a different bug, please reopen bug 83503.
It seems that 1) long subjects get wrapped 2) long From: addresses get clipped (below the beginning of the word Attachments) 3) long To: addresses push the attachments box to the right. As a result of 3), the virtual width of the entire panel is extended to the width of the header block, including the attachments list. This means a) attachments list may not be visible b) scroll bar for message list is outside the window, along with some columns from the right side of this display c) vertical scrollbar for message body is outside the window, making it easy to fail to notice there is more message below the visible pane d) Message body is wrapped at the (wide) virtual window size, meaning some text is outside the window, but there is no horizontal scrollbar. These comments are made against nightly build 2001072910, Solaris/SPARC, but it has been about like this for over a month.
*** Bug 92603 has been marked as a duplicate of this bug. ***
I'd love to fix this for 0.9.4, but it probably won't happen. at one point dbaron suggested looking into why the min-width on the header box wasn't doing the trick.
Target Milestone: --- → mozilla0.9.4
Blocks: advocacybugs
slide to 0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
This isn't as rare as you might think. Now that i know what's happening, with I'm seeing this probem with some regularity. Not extreme examples like the test case, but just enough warpage to push the scrollbars off the edge of the screen and make the window unusable. I recently saw a message with an attachment and long, but not absurdly long From address. something like... "superduper@superduper.org"<superduper@superduper.org> The longish email address was used as the "real name", in quotes and was followed by the a repeat of the address, with no space in between. This not extrordinarily long address didn't fit between the left edge of the screen and the attachment box so the message pane was warped and the message's scrollbar was pushed off the edge. Next time i'll try not to be in a hurry and save it to attach as a test case.
*** Bug 99374 has been marked as a duplicate of this bug. ***
*** Bug 101935 has been marked as a duplicate of this bug. ***
I see this frequently; it makes the mail window seem fundamentally broken.
Comment on attachment 43231 [details] [diff] [review] a fix, need mscott to review bad patch.
Attachment #43231 - Attachment is obsolete: true
moving out.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Looks like this is a dup if bug 47786. Marking so. Please excuse me and reopen, if I overlooked something. *** This bug has been marked as a duplicate of 47786 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
marking verified as a duplicate
Status: RESOLVED → VERIFIED
This bug was marked as a duplicate of 47786 but this bug has test cases and analysis and that bug does not. Reopening this bug and marking 47786 as a duplicate of this.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 47786 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.6 → mozilla0.9.7
over to mscott, as it is message pane related.
Assignee: sspitzer → mscott
Status: REOPENED → NEW
*** Bug 110257 has been marked as a duplicate of this bug. ***
*** Bug 110683 has been marked as a duplicate of this bug. ***
*** Bug 111945 has been marked as a duplicate of this bug. ***
This is happening very often on moderately long subject ( also *with* spaces!), where there is also an attachment. It makes the app look broken in most cases where there is an attachment. Suggest KW: nsCatFood, nsBeta1
during some recent performance optimizations the subject box lost it's flex. This stopped us from wrapping the subject line at all. I just put the flex back on it so we should be wrapping properly again for subjects with spaces.
*** Bug 111939 has been marked as a duplicate of this bug. ***
*** Bug 112306 has been marked as a duplicate of this bug. ***
*** Bug 113302 has been marked as a duplicate of this bug. ***
The bug that I submitted, 112306, is marked as a duplicate of this bug. While it is very similar to this bug, and is almost certainly closely related, it is still there on: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6+) Gecko/20011203 Also, the bug I submitted has been around for many months. It is not due to a recent change in Mozilla.
*** Bug 114233 has been marked as a duplicate of this bug. ***
Also note: if a message has a very long To: header (>30 addresses), AND that header is expanded, the message list & message pane are covered by the headers.
This bug is back to the normal severity is one in july (long subjects without any spaces cause the problem). For a brief period of time long subjects with spaces were causing the problem too (and this made it very severe) but I put the missing flex back which restored wrapping. Not a 097 stopper. We'll start taking a look at bugs like this once we are out of our performance freeze.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
I've exhausted my XUL and CSS knowledge, and I haven't found out how to stop a label's width from being less than the width of the longest word. Until that is fixed the only workaround seems to be to make the subject a single line.
ChatZilla inserts <wbr> elements (used to be 0px images) in long words, in order to allow mozilla to break them up. In addition, bug 99457 was filed to add a -moz[-pre]-force-wrap attribute to css, which would eliminate the need for the <wbr> hack. The splitLongWord function at http://lxr.mozilla.org/mozilla/source/extensions/irc/js/lib/utils.js#503 is used to find a nice place (a non-word character within a range of +/-5 of the desired break position) to insert the <wbr>.
This changes the label to a plain readonly textbox which while still only a single line is scrollable and usefully is also copyable, which solves another bug.
Another solution would be to use textboxes throughout the widget for all message headers, and then add some CSS to the skins so the textboxes look like usual labels. That would: 1) make the headers selectable (another mostfreq bug), 2) it would solve the wrapping problem, because too long subjects would overflow inside the <textbox/>. 3) it would solve *another* headers bug where the maximized header widget takes up all the space that the messagepane needs, making the email unreadable. Because we could set a max-height of the textbox. I really think this is what we should do, because it will fix a number of major bugs with message headers. Some problems with your patch, Neil: 1. Your patch touches a bunch of stuff which isn't at all related to this bug. 2. It only changes one label to be a textbox, so the widget will be inconsistent. 3. It doesn't fix all the other bugs in one fell swoop, like we could, if we go with my above suggestion.
Neil and I are discussing a fix to this bug...
Attached patch Correct patch (obsolete) — Splinter Review
It does help if I attach the right patch to the right bug... In this patch, ordinary header fields now are textboxes instead of labels. Also, all of the text in the To/CC lists is set to wrap.
Attachment #62202 - Attachment is obsolete: true
This patch fixes the problem for me (and for long from as well), with only changes to the CSS. (The changes to the XUL aren't really changes -- they're just indentation changes, since I got tired of reading XUL that was inconsistently indented to the point where a start-tag and the corresponding end-tag weren't even in a bunch of places.) This patch also has some other CSS cleanup -- fixing a few CSS errors, fixing the problem that the search box wouldn't allow the message tree or the message itself to get narrow when the window was narrowed, and fixing some namespace issues in messageBody.css. There are some comments in my CSS cleanup that are really questions, though...
dbaron, you change messageBody.css. Is that necessary? I thought, this file were only used for the *body* section, not the grey header area, while this bug is about the latter. The "header" stuff you see there are for headers displayed in the body section, e.g. from forwared msgs. I suspect it's offtopic, but since you attached the patch here, I'll respond here: You readd the namespaces, which previously caused the rules for the plaintext styling to break completely. Did you test that all that stuff still works? Please try - All the mail.*quote* backend prefs. - Normal (non-flowed) plaintext and format=flowed - Signatures with links - A smiley Make sure that everything looks as without your change. re your questions in the patch: > html|*.moz-signature > html|a > /* XXXldb What about visited links I don't care much, because it's just the sig. Add a rule, if you want, but make sure its color fits with the other sig colors. > and what about links within children? */ What is that? > html|*.moz-txt-sig > html|a, > html|*.moz-signature > html|a > /* XXXldb What about non-child descendants For .moz-txt-sig, they don't exist. The html is generated from plaintext, and there are no grandchilds of the .moz-sig-txt generated (unless you have a quote in the sig, maybe, but then you don't want the color change anyway). For .moz-signature (HTML signatures, composed and sent as HTML), they could exist. It's probably good to remove the >, if that change doesn't decrease perf. If it does, depends on how the renderer works - does it go up or down the doc while applying/checking selectors? In the latter case, it's no prob. Anyways, it's not important, because HTML sigs are likely to contain visual formatting like colors, which mess up our coloring anyways. > [background] > /* ... this should work now. How do I tell? */ I don't remember, maybe try to change the background color in the Nav prefs. > margin: inherit; /* XXXldb why? */ Because <blockquote> usually adds a top and bottom margin. This is not desired. <example type=source> somebody wrote: > hi there hi! </example> would generate (simplified): <example type=html-output> <pre> somebody wrote: </pre><blockquote type=cite><pre> hi there </pre></blockquote><pre> hi! </pre> </example> With the margin, it would look like: <example type=visual-output> sombody wrote: | hi there hi! </example> Obviously, this is wrong. The inherit removes the margin of the blockquote, by using the margin values of the parent node in the doc, which usually has no margin. > html|*.moz-text-plain[graphical-quote="false"] html|blockquote { > border-left: inherit; /* XXXldb why? */ Simiar here. In this mode, you should see ">"s. Since this is switched via CSS only, the usual indention and bar of <blockquote type=cite> is unwanted, or you'll end up with <example type=visual-output> somebody wrote: | > hi there </example>
dbaron, > @namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul); > @namespace html url(http://www.w3.org/1999/xhtml); Can't you just do something like @namespace url(http://www.w3.org/1999/xhtml); @namespace xul url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul); IIRC, most of the stuff is HTML, so this would improve readability, because you wouldn't have to add all those "HTML|*". Anyways, if the change is not required to fix this bug, I suggest that you file a new bug (and cc me) about this namespace change, because it is larger and has some risk (as previous regressions have shown).
Using the default value rather than 'inherit' would make much more sense if that's what you want.
*** Bug 116433 has been marked as a duplicate of this bug. ***
While this problem is much improved now, there is still the original problem with displaying the headers of messages with attachments: when the gray header area is open and the MailNews window is a bit narrow then the scrollbars for the subject and message panes are forced off the right edge of the window which makes them invisible. If this happened only when the window was unreasonable narrow then I'd say live with it, but narrowing the window even moderately will make the scroll- bars unavailable when the headers/attachments are displayed.
Attachment #62514 - Attachment is obsolete: true
*** Bug 101348 has been marked as a duplicate of this bug. ***
I haven't had a chance to look at these patches yet. I'll try to do that tby the end of the week.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
QA Contact: esther → trix
*** Bug 121626 has been marked as a duplicate of this bug. ***
This local folder contain an HTML e-mail 'Les nouvelles de DreamCity' which cause the 'preview' and the 'message list' panel to resize themselves. The message list panel loses its scroll bar. Also, as a side effect, when viewing this message the file, edit and all other menus becames very slow. What I want to say is that moving the mouse in these menus (when opened) is very slow (the blue 'reverse' line isn't able to follow the mouse, it is very late). If had scroll bar at right and are viewing the message 'Les nouvelles de DreamCity', while browsing the menus, the scroll bar will appear blinking and very weird. I don't know if this should be a new bug or not.
*** Bug 122247 has been marked as a duplicate of this bug. ***
*** Bug 123000 has been marked as a duplicate of this bug. ***
*** Bug 118029 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1+
Priority: -- → P2
Target Milestone: mozilla0.9.9 → mozilla1.0
*** Bug 126027 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0
Whiteboard: [ADT3]
Add "long CC-lists" to the cause of this bug in the subject line: OLD: emails with long subjects make it impossible to see the attachment tree and make thread pane go wild, if message pane is visible and you are not in "collapsed" header view. NEW: e-mails with long subjects (or CC-lists) make it impossible to see the attachment tree and make thread pane go wild, if message pane is visible and you are not in "collapsed" header view.
reassigning to ssu.
Assignee: mscott → ssu
This only includes the parts related to this bug. I spun off the messageBody.css mess into bug 130728, which I'll probably Future, and I'll just let the other CSS error fixes rot in my tree since nobody else cares much about CSS errors...
Attachment #62713 - Attachment is obsolete: true
Comment on attachment 73977 [details] [diff] [review] updated version of patch in attachment 62713 [details] [diff] [review], with only parts related to this bug Note that the change to msgHdrViewOverlay.xul is **only** an indentation change -- the file was inconsistently indented, and it confused my while trying to fix this bug. The CSS changes are all that's necessary to fix this bug. The changes to the rules with selector #searchBox fixes the same problem with the search box as the other changes fix for the header pane. Fixing the header pane doesn't do all that much good for small window sizes without the search box fix as well.
Comment on attachment 73977 [details] [diff] [review] updated version of patch in attachment 62713 [details] [diff] [review], with only parts related to this bug Actually, never mind. This patch doesn't seem to work for me anymore, at least for messages with attachments.
Attachment #73977 - Attachment is obsolete: true
Comment on attachment 73977 [details] [diff] [review] updated version of patch in attachment 62713 [details] [diff] [review], with only parts related to this bug Actually, never mind. This patch doesn't seem to work for me anymore, at least for messages with attachments.
Discussed in Mail News bug mtg with Engineering, QA, Mktng, PjM. Decided to minus this bug.
Blocks: 122274
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2alpha
I suggest mozilla.org reconsider *plussing* this bug because very many AOL users frequently send attachments (jokes, viruses, etc) to all their relatives or friends. AOL users seem to love to spam the people in their addressbook. Nevertheless, this bug will be highly visible to a large number of people. It is a kind of *in-your-face-brokenness*.
*** Bug 132796 has been marked as a duplicate of this bug. ***
This is one of the more visible mailnews UI problems. I hope that we can find resources to make this happen. adding mozilla1.0+ keyword.
Keywords: mozilla1.0mozilla1.0+
This is #27 in our list of most duplicated bugs. It affects people with lower resolution screens the most. People with 640x480 screens will see this a lot and people at netscape who maximize the mail window on their ultra high res 21" monitors will probably rarely ever see it. Workaround for this bug: Buy a g4 with a new 23" cinema displays. =)
While I also think this should be fixed, we should note that the product is designed for a minimum display size of 800X600, users with only 640X480 are bound to be dissatisfied.
This is NOT just a problem when running 640x480. I run 1600x1200, and run into this bug almost every day. I imagine that most people do not run Mozilla maximized to the size of the screen.
You mean you get a message which has a huge number of characters in the subject without a space very day? We properly wrap long subjects if there is a space in the subject. The problem is when there isn't a space.
This bug has accumulated a number of related bugs, for example one I submitted: http://bugzilla.mozilla.org/show_bug.cgi?id=91662#c47 That is why there are so many duplicate bugs attached to this one. Specifically, the place where it is triggered for me is when an email or posting has an attachment, along with some long names in the To: or CC: header. And yes I do get those almost daily.
I also get mail with long To or Cc addresses and attachments most days. My screen is 1280x1024, but I don't have the mailnews window maximised - I usually have it over roughly the left half of the screen with a browser window next to it in the right half. The biggest problem for me with this bug is that I sometimes miss the fact that the whole message is not visible on the screen, as the scrollbar is invisible.
This isn't just about ridiculously long subjects as in the test case i wrote. Changing summary to hopefully make it more clear. This also happens with relatively normal looking mail. A lot of from addresses come in the form: "user@isp.net"<user@isp.net> (Note that there is no space between the quote and the brace). If such a person sends a mail with an attachment, then their email address doesn't have to be very long before it doesn't fit and starts pushing stuff off the right edge of the window. It doesn't have to push very far before the scroll bars fall off the right edge of the window and make the window unusable. See comment 28. It happens to me a lot less often now that i rarely use my 800x600 laptop. Old Summary: Emails with long subjects make it impossible to see the attachment tree and make thread pane go wild, if message pane is visible and you are not in "collapsed" header view. New Summary: Long strings in mail header cause scroll bars and attachment window to disappear, making message unviewable.
Summary: emails with long subjects make it impossible to see the attachment tree and make thread pane go wild, if message pane is visible and you are not in "collapsed" header view. → Changing summary to hopefully make it more clear. This isn't just about ridiculously long subjects as in the test case i wrote. This also happens with relatively normal looking mail. It happens to me a lot less often to me now that i don't use my 800x…
LOL. Bugzilla handled that quite gracefully. Dawn, you might want to change the summary again :) Just to add something relevant to this bug. Every single user I've encoutered during my time in tech support have their email client maximized. The best fix for this is a simple one: place the header in the message pane.
fixing summary... Dawn wins the Longest Summary Award!
Summary: Changing summary to hopefully make it more clear. This isn't just about ridiculously long subjects as in the test case i wrote. This also happens with relatively normal looking mail. It happens to me a lot less often to me now that i don't use my 800x… → Long strings in mail header cause scroll bars and attachment window to disappear, making message unviewable.
*** Bug 121905 has been marked as a duplicate of this bug. ***
This shows how simply including the attachment pane with LONG e-mail addresses (which include spaces) and a short subject, cause a similar issue to that which is described by this problem.
This image is of the same mail window as attachment #76566 [details], but the message being displayed doesn't have an attachment. Note missing scroll bar for the message list in attachment #76566 [details]. These are with Mozilla 0.9.9.
Didn't know this bug existed--been seeing this for a long time. There's another artifact I've found, can anyone confirm it? If the display is busted like attachment 76566 [details] and you mouseover a link in the content pane, it causes the chrome part (the list of messages) to "vibrate." That is, it resizes itself so that the rightmost edge of the content (which was beyond the edge of the window) moves at the right edge of the window even though that overlaps the list of accounts to its left... only to move back an instant later. This happens again when you mouseoff a link. Running the mouse up and down a link in the message body should demonstrate this easily.
Yes. I've seen vibrating chrome in MailNews, but hadn't bothered to work out when it happens. As it mostly seems to show up at the same time as this this bug, I presumed it will go away when this is fixed properly.
*** Bug 138785 has been marked as a duplicate of this bug. ***
*** Bug 139406 has been marked as a duplicate of this bug. ***
*** Bug 139461 has been marked as a duplicate of this bug. ***
I noticed that the bug will only appear when you use windowing layout that features the biggest message panel (ie, 2-upper-1-lower). clearing old mozilla settings would NOT help. I think the display issue could be avoided by shortening those long header fields (from:, to:, subject: ...). That is, by replacing "To: sadfkljasdklsdklfjasdklfjsdklfj@fdsjfklasdjfklasdasdfsdfs.com" with soemthing like "To: sadfkljasdk..." of course, the real content was not changed, only the display. BTW, #139461 has test cases. also got a image of the error.
I just noticed that there was no scroll-bar when there were more attachments that could be displayed in the attachment box.
There *is* a scrollbar. You just can't see it *MOST* of the time because this bug causes the scrollbar to move off-screen as soon as *any* element in the header (subject, From, To, or attachment filename) is wider than the header itself. :(
*** Bug 140265 has been marked as a duplicate of this bug. ***
Are the "vibrating panel separator" and "losing scrollbar and attachment windows" bugs really the same? If so, could we put the "vibrating panel separator" into the summary as well. If not, we need another bug. For the record, I get the "vibrating panel separator" problem but not the missing scrollbar etc. problem. It isn't obviously related to long strings in the headers either, at least for me. Build is Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9+) Gecko/20020424 (sparc solaris). Raphael
the vibrating panel button is a different bug. It's a recent regression that causes some windows to go into an infinite reflow loop where a scroll bar is added then removed then added again, etc. We're trying to find a fix. It's a top moz 1.0 bug: Bug #121583.
> It isn't obviously related to long strings in the headers either... True, it has to be *one* long string (as in a lond e-mail address), or a medium string and an attachment (as soon as the attachment window AND/OR the string are wider than the mail window (which is pretty often, if you ask me). :(
*** Bug 136183 has been marked as a duplicate of this bug. ***
*** Bug 144577 has been marked as a duplicate of this bug. ***
*** Bug 93994 has been marked as a duplicate of this bug. ***
I believe bug 142988 is a dupe of this ... I haven't paid much attention to this bug and it's too much to read right now (sorry) - can someone that knows exactly what this bug is on about review 142988 and set the dupe field appropriately if it turns out to be the same thing. Ta
*** Bug 142988 has been marked as a duplicate of this bug. ***
*** Bug 144537 has been marked as a duplicate of this bug. ***
*** Bug 145039 has been marked as a duplicate of this bug. ***
I'd recommend that the priority gets increased; it almost *always* breaks news articles with attachments because news articles almost inevitably have a very long line indicating the route that the article took to my news server: Path: mindspring!newsfeed0.news.atl.earthlink.net!news.atl.earthlink.net!washdc3-snh1.gtei.net!cpk-news-hub1.bbnplanet.com!news.gtei.net!newscon02.news.prodigy.com!prodigy.com!howland.erols.net!news-out.worldnet.att.net.MISMATCH!wn4feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi.com!rwcrnsc52.ops.asp.att.net.POSTED!not-for-mail (I also had to use a different news client just to paste this in, because Mozilla won't let you cut-n-paste mail headers, another critical problem.) This simply makes Mozilla unusable for reading news with attachments.
*** Bug 132909 has been marked as a duplicate of this bug. ***
See http://bugzilla.mozilla.org/showattachment.cgi?attach_id=75670 for example of this happening with a news message that has a long Path: header. Almost all news messages have a long path header. Notce that the scrollbars are gone from BOTH the message list and the message itself.
Adjusting summary to reflect news phenomena.
Summary: Long strings in mail header cause scroll bars and attachment window to disappear, making message unviewable. → Long strings in mail or news header cause scroll bars and attachment window to disappear, making message unreadable
Bug 132909 duped to this was severity "major". This should be the same or worse. See bug 132909 screenshots. Mozilla currently as a newsreader is clearly inferior to Netscape 4. This ought to be 4xp as well.
As far as I can see, this bug depends on bug 99457. Marking dependency.
Depends on: 99457
Not really, since we can clip the long lines instead of expanding the window.
guys, I just noticed that I could drag the vertical spliter bar (the one that sseparate the upper 2 listbox) to the left till it CROSSED the scrollbar of the folder list listbox momentarily. You need to use 3-window mode, and maybe large fonts in Window$' scheme, 800x600 resolution. This behaviour may be relatd to this bug, but I am not sure. I will attach an image...
guys, I just noticed that I could drag the vertical spliter bar (the one that sseparate the upper 2 listbox) to the left till it CROSSED the scrollbar of the folder list listbox momentarily. You need to use 3-window mode, and maybe large fonts in Window$' scheme, 800x600 resolution. This behaviour may be relatd to this bug, but I am not sure. I will attach an image...
when this e-mail is viewed the message list suddenly becomes only 1.5 emails tall but goes back to the regular height when a new e-mail is selected. You can see that this bug manifests itself a little differenly on windows but is still very very annoying and should be fixed before the release of 1.0
I think that comment 124 is another bug. This bug is about scrollbars disappearing. Yours appear to be intact.
I think comment 124 is the correct behaviour when headers are too high. With "All" headers view it always moves the horizontal split to fit the header info on the screen.
Keywords: 4xp
There is a pathch in bug 106927 comment #97 that may also fix this bug. What it does: "It changes the tab container so that when the tabs overflow, they are cropped on the right-hand side, instead of growing the container and pushing the rest of the UI off screen." Could this be used to fix this bug? Even if it may not be an ideal fix, please consider if it will at least be better that the current situation. If so, the patch is already there waiting...
Note in that bug that I said that the *concept* and not the patch itself will fix this bug. I am currently seeing if I can apply the same concept to this problem, but somebody with more (as in any) XUL experience should look at this.
... and I meant to say in my last comment, *could* fix this bug, not *will* fix this bug. Upon investigation, it is not the container, but the text itself that is causing the problem. Therefore, the only way to fix this is to change the text fields to a different type or change the inherent properties of the text field. Probably the latter considering that the fields were changed to this special header type from generic text fields. That is unless there's some special container type that I don't know about. This bug and bug 61497 could probably be fixed relatively easily at the same time. While experimenting, I did come up with a quick fix. Splitter bars can be added to components like the headers, which enables the offending strings to be collapsed. That's not a very good solution, though.
This patch allows embedded spaces in email addresses to wrap.
*** Bug 152511 has been marked as a duplicate of this bug. ***
Blocks: 1.1b
*** Bug 153316 has been marked as a duplicate of this bug. ***
Oops, previous patch broke the context menu.
Attachment #87655 - Attachment is obsolete: true
*** Bug 154077 has been marked as a duplicate of this bug. ***
*** Bug 154544 has been marked as a duplicate of this bug. ***
*** Bug 155249 has been marked as a duplicate of this bug. ***
Comment on attachment 89053 [details] [diff] [review] Revised email address patch I haven't applied the patch, but one obvious thing I see is that the UpdateMessageHeaders() call should not be moved into buildLongView(). It needs to be left in toggleAddressView(). The comment has a typo. It should indicate that UpdateMessageHeaders() should not be called from "buildLongView()" (as opposed to "buildView()") I'm still reviewing the patch.
*** Bug 157227 has been marked as a duplicate of this bug. ***
sean, neil, what's the status of this bug/patch?
Blocks: 1.1
No longer blocks: 1.1b
Blocks: 158464
Blocks: 18687
*** Bug 160124 has been marked as a duplicate of this bug. ***
As v1.1 has branched, and there hasn't been much recent activity (last was almost a month ago), should this still be a blocker for v1.1's release? I say that as this bug isn't, IMHO, high profile in that it only happens under rare circumstances.
Don't understand about it being rare circumstances. I get emails with long cc lists every day! This makes the scroll bars disappear. Also, if after displaying full header the header is made brief (by clicking on the pointer) the header info stays in the content pane! This is NOT an obscure problem!
On the contrary I use Mozilla mail in the office connecting to an Exchange IMAP server and every time someone sends an email to a preconfigured address list, the email address formed is so long that it causes the problem. I see this bug several times every day, and would certainly appreciate a fix for it. I've found ways to work around it so it's not a major issue but it is a blot against an otherwise excellent email tool. Thanks David.
Just by looking at the cc list/votes one can see this is NOT an obscure or infrequent problem. It is being tolerated on a daily basis on the faint hope that it will get fixed eventually. It is a real nuicance and makes the mail reader unuseable when long subject/gecos fields are recieved since you either lose the scroll bars, lose the attachments pane, or get continuous jittering of the message pane.
I agree, its not obscure. Its a day-to-day fact of life using the Mozilla mail front end for many users. Most of the problems it causes are minor but it is very visible. I'm not really in a position to say if it should be a 1.1 blocker, but I would have thought the whole point of 1.1 was to fix many of the visible/annoying/serious bugs that couldn't safely be handled in 1.0.
As an amateur programmer for 25 years I've created a lot of bugs myself, and fixed a lot also. My observation has been that when a bug is this hard to fix it's because the program design was wrong from the beginning. The first time I used mozilla I remarked that putting the headers in a separate panel seemed an odd and unnecessary thing to do, and I still think so. Other mail readers stuff the headers in the same panel with the message and do just fine. I would strongly urge you to do the same and move on to something more important!
No longer blocks: 1.1
I believe Walter is right, if we cannot fix the bug easily by adding fixes, probably the whole concept needs to be rethaught. Therefore we should review the reasons why it has been implemented in the way it is now and see if other concepts would reduce the usability of the solution or not. Based on this evaluation we would need to agree on an alternative concept that provides at least the same functionality without the same defects.
I work with graphics and it is impossible to receive graphic attachments, fonts, etc with this bug. I have to go to another mail reader to use my mail. I *hate* using Outlook Express. This is *not* trivial.
Walter Sheets: See bug 9942 to see about Mozilla putting headers in the message window.
I looked at the previous discussion in Bug 9942 and the only thing I can see that is compelling is the argument that users are expecting scrollable, selectable headers. I want to go on record as NOT expecting scrollable, selectable headers! I much prefer to have the headers inline if I want to see them, and invisible if I don't want to see them. The argument for converting inherently non-HTML text (i.e. headers) into HTML is a specious one, IMHO. Do you want to click on an email address to send a response? So click on REPLY or some variation thereof. Do you want to fetch a referenced message I.D.? So click on FETCH PARENT ARTICLE or some variation thereof. Do you want to forward headers to an abuse department? (Hah!) Then click on some variation of FORWARD HEADERS. I think the proper design goal is to identify what tasks the user might have and then design a button or menu item to accomodate that task, rather than to force an inherently un-natural conversion between hostile formats (HTML being the hostile format, of course ;-)
The things I picked up on from the other thread were: the twisty; the attachment pane; and skinnability. None of these seem absolutely vital. Sure, it's nice to have the twisty instead of the NS4 view menu options, and its nice to have that little pane with the attachments, but not at the expense of it not working. Skinnability seems like a non-issue, if the headers are displayed as text they will look like text and there will be no need to mess with chrome. The current implementation has clickable addresses but not the ability to select text, in particular from the subject line - that's a nuisance but not a serious problem. But I think there absolutely has to be a way of seeing the entire header when it is very large, and it seems like making it scrollable is the sensible. I guess you could do that by making the pane scrollable or by putting the header inline. Putting the header as inline text might be a little less slick but at least it would work, until and unless someone can program that pane to work correctly.
Having selectable elements in headers is very important in many ways. Obvious point, how many times do you get an email where the subject contains a URL? In my case, very often, both from script generated email and friends who send things like "Have you seen http://www.web.site.com?" As well, often the subject contains an email address that you want to use. If you can't even select the text, not only can you not click on it to view the URL or mailto the email address, you can't copy and paste it. You have to retype it, which gets silly with a 80 character alphanumeric GET query URL. I use a lot of scripts that send myself web pages and such, with the URL in the subject and the body as the content. So not only do I often want to use the subject headers to click on to go to a page, which I can't, I can't select the URL and paste it into the browser, and because the scroll bar is gone, I can't view the page in the message window either. So I end up basically screwed, or using some workaround like grepping the URL from the Inbox file in .mozilla, or clicking on a link on the page that I know links back to the page I really wanted. To summarize again, depending on user practice, this bug can be fairly crippling. So... I would certainly put functionality ahead of sexiness, what good is having my message header skinned with brushed titanium while I'm grepping my Inbox to pull out a URL?
Let me say, however, that the attachments pane is pretty useful and shouldn't be removed without second thought!
Netscape 3 & 4 mail did and do work fine. Mozilla trying to be like M$ O/OE stinks. Mozilla for mail and news is currently little better than useless (not just because of this bug). Let's make it work now and add flash later if flash is really needed and/or wanted. Scrap chrome message headers.
I use mozilla mail every day, so I don't agree that it's next to useless, but I rarely look at headers, and the only URL's I ever see in the subject line are obvious spam :-( (Different strokes...) Is there a technical reason the header pane can't have a separate horizontal scrollbar to take care of the long-header problem? If it's a shortcoming of the API/toolkit then the design of the program must be changed to fit the available tools. Otherwise, it seems to me that the horizontal scrollbar is the obvious solution, no?
You must be easy to please. I actually use 4xp routinely for mailnews.Here's a partial list of why I wrote what I wrote: Bug 4302 - over five years old; works fine in 4xp Bug 21344 - 4xp superior Bug 54911- another 4xp superiority Bug 109935 - pure slop Bug 118899 - 4xp ho hum Bug 129052 - hard to imagine something so simply useful was discarded Bug 134333 - more XUL slop Bug 134635 - & Bug 135964 - & Bug 148267 - & The browser is first class, Mailnews is last class.
Okay, I'll ask.. I surely can't be the only person reading that last comment that's wondering what on earth 4XP is. What's 4xp ? (and feel free to flame me.. as that seems to be the norm when I ask something about a bug in here. All flames will be tidily placed in /dev/null)
I'm another one who hits this bug every day. On the rare occasions I need to copy something out of the header fields, I use view page source (ctrl-u) to see the headers as text.
I was quite surprised when a mail dropped into my mail box suggesting this is not a siginficant problem. It is. The smaller your secreen, the more of a problem it is. If you wish to use 800x600, or have to, you'll be in trouble. Similarly it will make use of the mozilla mail reader v. difficult for the visually imparied. Even I, using an 1600x1200 screen often find e-mail messages that screw with the scrollbars. It makes some particularly mangled spam especially annoying.
I suggest a possible fix for this bug: 1) In the message preview window (messenger.xul), make the attachmentBox's flex=1 and make the text of Subject, From, To, etc. "croppable"; 2) In the message window (messageWindow.xul), put attachmentBox below the To, CC items, rather than right of the header pane.
I just looked at Sun's StarOffice 5.2 which appears to have done already what mozilla is aiming at. Perhaps Kyle was also referring to their work. The header panel is in the center with a vertical separator between the headers and the list of attachments. The vertical separator can be moved with the mouse as far as desired in either direction, even so far as to obliterate the headers or the list of attachments if you want When the main window is narrowed, the width of the attachments pane stays constant and the header window shrinks as much as needed while the headers wrap automatically rather than truncate--all the way down to zero if you want. This inherently solves the long header problem. Whether you like their approach is another question, but it works. There are no horizontal sliders in either pane, though I can't see why you couldn't add one to the header pane if you don't like the wrapping headers. The location of the combined header/attachment pane also re-locates itself automatically up along side the article list, so as to accomodate large images in the body pane as needed.
the simplest and possibly quickest solution is to display long lines with this format: "this is a very long .... long time" use "..." to represent the mess in the middle.
*** Bug 162485 has been marked as a duplicate of this bug. ***
*** Bug 146359 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
Sean Su wrote: > (From update of attachment 89053 [details] [diff] [review]) > I haven't applied the patch, but one obvious thing I see is that the > UpdateMessageHeaders() call should not be moved into buildLongView(). > It needs to be left in toggleAddressView(). Sorry, my fault for not checking the diff, you can ignore that bit.
ok, I think I have the start of the fix for this bug. at least, I have a hack. I'm trying to get crop to work, through xbl. I'm not having luck yet, but I know it can be done. here's a hack that changes the code to not use the xbl widget mail-toggle-headerfield. instead, I've exploded it out into the xul. when I do that, crop works. but when it's an xbl widget, I can't (yet) get crop to work.
Attached patch hack. (obsolete) — Splinter Review
taking back from ssu. what I'm trying to do is get it so the headerValue label in the mail-toggle- headerfield widget (see mailWidgets.xml) will crop. this isn't working: <xul:label class="headerValue" anonid="headerValue" crop="right" flex="1">*</xul:label>
Assignee: ssu → sspitzer
Attachment #96617 - Attachment is obsolete: true
accepting. here comes a screen shot...
Status: NEW → ASSIGNED
re-reading the bug, it sounds like other headers (besides subject) can cause this to happen. once I get a review for the subject fix, I can look into the other headers.
For the record, this works: <xul:label class="headerValue" crop="right" anonid="headerValue" value="*" flex="1"/> But this doesnt: <xul:label class="headerValue" crop="right" anonid="headerValue" flex="1"/>*</label> I think that makes sense, because in the second case, "*" (or the subject) is just a child node of the label, instead of the value.
Seth: It's the PATH header that seems to be the longest and most problematic as far as I can tell from the activity in the groups.
Attached patch patch for all headers (obsolete) — Splinter Review
patch that fixes all headers. now that we aren't doing the .firstChild thing, we probably don't need to default the value to "*". I'll try that, and supply a new patch.
Attachment #96618 - Attachment is obsolete: true
Attached patch remove value="*", not needed (obsolete) — Splinter Review
this patch fixes the long "Path" header problem that jay garcia mentioned.
Attachment #96636 - Attachment is obsolete: true
I would like to wrap the text rather than crop it, because then we will lose the way to see the whole content of mail header in the preview pane even in the messageWindow.xul.
Please wrap instead of crop.
Please wrap instead of crop. The *entire* subject line must be readable.
how would you wrap something like: "nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn"? Insanely long subjects are available in: 1) the 3 pane window title, when the message is selected 2) the stand alone msg window 3) view message source On problem with wrapping (especially in the preview pane) is it can make the header area too big (after this patch, too tall), and force the body of the message off screen, requiring the user to scroll.
note, the you'll be able to see more of the subject (and other long headers) in the stand alone msg window than in the preview pane, since the header area will be bigger. also, this patch makes us behave like Outlook Express.
No. The ENTIRE subject must be readable in the preview pane, because: 1) The window title is *not* long enough to show long subjects (and we shouldn't be relying on this anyhow!). 2) I _never_ use the stand alone message window (and we shouldn't be relying on this anyhow!). 3) We should not expect users to go to (let alone know about) "view message source" (and we should _definately_ not be relying on this anyhow!). Even the most extremely long subject line (~255 caracters) will almost certainly never make the header so tall as to make the body unreadable. On the other hand, CUTTING OFF the subject will most certainly make the subject of the message UNREADABLE. I frequently whitness e-mails (usually from Lotus Bloates users) where the (long) subject line contains the actual message (and the body is left empty). For this case alone, we should make absolutely sure that the entire subject line is readable in the preview pane's header. Now to your (unlikely) example of a long subject without spaces: At a minimum, we should be checking if there are spaces (say: at least every 20 letters) in the subject line and create the linewrap(s) there. Only _IF_ there are _no_ (or insufficient) spaces would I agree to cutting off the subject line. But, even if there are NO SPACES, there must be some way to wrap. Perhaps _forcing_ a wrap at the right border position, regardless if its in the middle of a word or not: ThisIsAVeryLongSentenceWithoutAnySpacesToShowHowWrappingShouldBeForcedRegardle ssOfWhereTheWordEnds PS. LookOut Express sucks Donkey-Dung, and shouldn't be our excuse to take the easy route.
Seth, if you're going to crop the headers you might as well switch them for textboxes (as per attachment 70284 [details] [diff] [review]) thereby simultaneously fixing bug 61497.
> how would you wrap something like: [...] Force a break after n chars. > 1) the 3 pane window title, when the message is selected This is a bug. > 3) view message source This is for experts only. Showing at least a reasonably long part of the subject (e.g. 300 chars) is important. E.g. some clueless users write the first line of the msg in the Subject. In other cases, important information like a tracking ID is only in the later part of the subject (a bug of the sending software, it should also be in the body, but happens nevertheless, IIRC). > On problem with wrapping (especially in the preview pane) is it can make the > header area too big (after this patch, too tall), and force the body of the > message off screen, requiring the user to scroll. IMO, the subject is more important than the body. Is there a possibility to make a whole frameset scroll? (If not, would it be easy to code?) In that case, the whole msg pane could be the frameset, with the header pane as the upper frame and the body document as the lower frame. They would scoll together, giving an effect similar to 4.x, but with the advantages of XUL in the header, including different trustness of header/body.
note to neil: making it so we can select and copy header text is next. But I want to talk to some xul people (especially hewitt), who had some ideas on how to do this without using a textarea. note to others: 1) consider the "badness" of the original bug, and that this patch fixes it. 2) the preview pane is small. with such limited space, anything we do will have issues. You can't fit 10 pounds of headers into a 5 pound bag. note to peter: "LookOut Express sucks Donkey-Dung, and shouldn't be our excuse to take the easy route." Continue with these unprofessional and useless comments and I'll ask staff@mozilla.org to remove your bugzilla access.
Please note that this bug is usualy caused by long e-mail addresses (because they are contiguous), and not subject lines (because they are rarely contiguous). IMO, cutting off subject lines will do little to fix this bug (and a lot toward making mail/news worse). Seth: I apologize for the "unprofessional" comment. I sometimes get frustrated when things seem obvious to me. I should have said: "We shouldn't follow OutLooks example in cases when it is setting a poor example."
Please notice that the vertical scrollbar on the message pane is still visible (and not moved off-screen). If any "cropping" is to be done, then please only of the e-mail addresses.
Simply saying that is how OE does it without asserting that OE does it "right" is sort of like saying OE is a usability leader <choke> that Mozilla should follow instead of Mozilla taking the role of usability leader.
Seth: I applied your patch, but unfortunately, it crops the the subject in the stand alone msg window too. So all of your way to show the whole subject line in comment 180 is not reasonable.
Comment on attachment 96637 [details] [diff] [review] remove value="*", not needed > .setAttribute('value', val); This should be .value = val;
Perhaps you could use twisties to switch between cropped and wrapped view?
For the time being, I suggest to wrap lines on chars like ".@<" for addresses and "!" for paths. This will make this bug less visible ;-)
Comment on attachment 96637 [details] [diff] [review] remove value="*", not needed Actually the headerValue should inherit its value attribute so that the setter can just set an attribute. <xul:label class="headerValue" flex="1" crop="right" xbl:inherits="value"/> <property name="headerValue" onset="this.setAttribute( 'value', val ); return val;" onget="return this.getAttribute( 'value' );"/>
My personal opinion: I like Seth's patch, but there should be some simple way for displaying whole subject line or other headers. What about using tooltips ?
Jan: don't tooltips have a size limit as well? Seth: please be sure to make header copy accessible.
neil's textbox approach is exactly what we want. my apologies to neil (again). some of his earlier patches had the desire fix, but I let them bit rot. with neils approach, we get: 1) the fix for the badness 2) scrolling subject line (you can scroll and see it all) 3) you can copy and paste headers now (except for email headers) addressing neil's comments: 1) > .setAttribute('value', val); This should be .value = val; fixed that, thanks. 2) Actually the headerValue should inherit its value attribute so that the setter can just set an attribute. <xul:label class="headerValue" flex="1" crop="right" xbl:inherits="value"/> <property name="headerValue" onset="this.setAttribute( 'value', val ); return val;" onget="return this.getAttribute( 'value' );"/> we don't need the getter, so I've left it as is.
Attached patch based on neil's patches. (obsolete) — Splinter Review
patch for review. neil, with this patch (based on your patches) two of the most painful mailnews bugs are fixed. you rule!
Attachment #96637 - Attachment is obsolete: true
Comment on attachment 97132 [details] [diff] [review] based on neil's patches. this patch works fine, but IMO, you should do the same job for the From/To/CC fields too.
> 2) scrolling subject line (you can scroll and see it all) Please make the subject _wrap_ to the next line. It is important to be able to see and read the entire subject without parts of it always being concealed. Could you post a screenshot of this "scrolling" behavior?
Seth, I think you also need to twiddle some JS in msgHdrViewOverlay.js
got distracted by stand alone mail and some performance work. I'll finish this up today.
Attachment #97132 - Attachment is obsolete: true
Attachment #97164 - Attachment is obsolete: true
Comment on attachment 97874 [details] [diff] [review] patch, also works with keywords [checked in: Comment #206] sr=bienvenu
Attachment #97874 - Flags: superreview+
Comment on attachment 97874 [details] [diff] [review] patch, also works with keywords [checked in: Comment #206] r=ben@netscape.com
Attachment #97874 - Flags: review+
Comment on attachment 97874 [details] [diff] [review] patch, also works with keywords [checked in: Comment #206] a=asa (on behalf of drivers) for checkin to 1.2a
Attachment #97874 - Flags: approval+
fixed. I'm going to spin up a new bug about subject wrapping.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → FIXED
I don't believe this bug is completely fixed. I have an email (attached) which, with my current small screen resolution will cause the To: header to push the scrollbars out of the current window. This screenshot is of a current Linux CVS pull where the patch *has* been applied. (I do get a scrolling subject with other mails.) Unfortunately I don't have permissions to reopen this bug.
Seth, attachment 89053 [details] [diff] [review] is designed to alleviate that bug by allowing email address to wrap internally (although ssu pointed out a mistake in that patch).
*** Bug 135308 has been marked as a duplicate of this bug. ***
This landing may have caused the regression seen in bug 167468
*** Bug 147347 has been marked as a duplicate of this bug. ***
Hi, I just tried Mozilla 1.2a, but this bug seems not to be completly fixed, because I got an email with attachment and the long TO-field is pushing the scrollbars out of the window. Please reopen this bug report. Frank Loeffler
I am reopening since this is not fixed. The attachment window still disappears if you have a messages with a long gecos field. Happens with todays build on Solaris 5.x with cvs 20020912
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Solaris 8, Nightly build 2002092322 This bug still pushes the scrollbars out of view with long email addresses, but the partial fix seems to make things worse in other ways too. It attempts to make more space by pushing the divider between the folder list (left panel) and the header/body panels over to the left, truncating all the folder names to be unreadable (just an icon and ...). In the process of doing this, there is a lot of left-right shaking of the display panels as it tries to determine how far this can be pushed.
*** Bug 172205 has been marked as a duplicate of this bug. ***
There's another case to note. I'm pasting below two subject lines from spam mail I've received, that contain lots of spaces. Subject: babes babes and more babes 7247iOrL7-135tFMl5959iswz0-114pj-30 Subject: This is REAL! 5375pohY6-992TSGt8250EBNG0-515-28 I think their point is to be very long as to hide the last part from the user --either my id in the spammer's mailing list, or the campaing's id the message belongs. Mozilla does not wrap the subject line. All spaces are displayed and the last token is pushed to the edge of the window and part of it is hidden. (Just checked with 2002100504 on a linux box) I suppose that collapsing space wouldn't harm anything. Space does not have to be preserved in headers, right?
The "fix" for this bug unfortunately made things *worse* than they were before. The subject rarely (if ever!) was the cause of this bug. Ironically, the main cause of this bug - namely long e-mail addresses - remains unfixed. Also, the bug to reinstate subject line wrapping (bug 166892) has been dead in the water ever since it was filed. Please, Please, Please reverse the patch for this bug (since it doesn't fix anything anyhow) until a solution is found that doesn't break subject line wrapping.
I have found an instructive message that causes this problem in Build 2002082611. It is a multipart MIME which combines the text and HTML versions of the message, for which the mail client is intended to display the HTML part if HTML is selected as the viewing mode. Subject and email addresses are not very long. Has attachments. It not only causes the scrollbars to disappear in the message pane, but causes the settings for the fields to be displayed in the message listing (I have Subject, Sender, Date, Size and Flag) back to the default settings of just Subject, Sender, and Date. One can view the message by switching to text mode and using the PgUp/PgDn keys or the mousewheel. If anyone is interested, I can send the message for diagnosis. The problem also appears if one double-clicks to get the message in a new window. It would seem that the solution would be to make the message viewing pane/window a complete browser display. This problem doesn't seem to occur when browsing the same HTML, if it is saved to an external file, stripped, and then viewed with the browser.
*** Bug 174046 has been marked as a duplicate of this bug. ***
*** Bug 176249 has been marked as a duplicate of this bug. ***
Attached image screen shot
Screen shot of the bug on W2k caused by long list of cc recipients
*** Bug 177234 has been marked as a duplicate of this bug. ***
On my ISP's news server (nntp.ix.netcom.com), every message does this due to a long 'path' header.
I don't understand why people insist on keeping this bug open. It has been fixed. Period. Noone promised it won't show if you use screen resolutions like 640x480... Re: comment 222: I don't see this bug on the provided screenshot. In fact, I don't see anything wrong on this screenshot... Re: comment 224: The screenshot shows _this_ bug, but I can't reproduce it anymore, since the patch has landed. Paths in news posts appear in textboxes like anything else. What build you were using, Bill?
This bug is still easily reproducable on: Mozilla 1.2b Mozilla/5.0 (X11; U; OpenVMS COMPAQ_AlphaServer_DS10_466_MHz; en-US; rv:1.2b) Gecko/20021022
The bug is still present (for long To/Cc addresses) on SPARC/Solaris8 using nightly build 2002110622, although not as extreme as previously, as now the left-hand panel (folder display) collapses to only showing fiolder icons and ellipsis before pushing the scrollbars/attachment list off the right side. An effect of this resizing of panels is that there is a LOT of flickering and redrawing when changing from one mail message to another, as the panels need to resize and be rerendered,and it all seems to happen several times as they sort out their relative sizes. I typically have the mail window about 700-800 pixels wide, so I can also see other windows on my screen, and frequently get mail with attachments and email addresses long enough to show this bug.
This bug has been alleviated (as of 1.2b), not fixed. The scrollbars and attachment window still disappear, just less frequently than they did before, for me at least. Now, I find the pane jittering and difficulty manually resizing the panes a significant problem.
This bug has been around for me for a while and it still present in the 1.2 Linux build released yesterday 11/26/02. The bug makes it impossible to drag and drop a message into a folder as well as making it impossible to use the scrollbars.
WHY OH WHY... does the content of the header cause ANY resizing at all? I suggest the headers panel be a small HTML view that uses normal HTML to display bold, mailto's etc. This would a) mean that the thing never resized depending on it's content b) allow the whole thing to be copied as one piece, or selective parts of it (for example a part of an email address) c) standardise all the actions on email addresses d) make it really simple e) Provide a scrollbar for the header if it was really long It's annoyed me for some time that the headers are so restrictive, and then I had this bug where it started hiding things and resizing :( why not cut through all the crap?
I am getting the problem in 1.2.1 for long to or cc headers. I think that (disableable) tooltips would be a good idea for these long headers (including the subject header which appears to have been otherwise fixed). Either that or a discrete arrowhead for dropping down a dialog with the full (wrapped) header. The latter may look more professional.
People keep sending me URLs in subject with an empty body; I cannot cut & paste text in tooltips, so this would be a disadvantage for me; expandable subject line sounds good.
Does anyone else experience the spastic thrashing and pane resizing whenever they mouseover a menu or toolbar button?
Only when the pane is squashed by a wide address header and attachment box.
Attached image Cut scrollbar
Here is a case where the folder scrollbar is cut off. Also, the status bar disappears. It is caused by a vertically long expanded header. Build ID 20020208.
Sorry, typo. I meant 2002120208. It still happens in 2002121008, latest nightly.
*** Bug 153297 has been marked as a duplicate of this bug. ***
time to update the target milestone for this bug? still reads 1.2b
Flags: blocking1.3b?
Flags: blocking1.3b? → blocking1.3b-
*** Bug 113840 has been marked as a duplicate of this bug. ***
The resizing of the preview window based on the header content is very anoying, and it seems to take the news client several tries to come up with one that fits. My preference is that I set the size of the windows, and sub-windows, and if the content does not fit, I should be able to scroll it, manually resize the window, or click on a button to display the expanded content.
I have been seeing this problem for quite a while and it happens whenever long addresses are in the CC fields. I agree with comment 240 about fixing the address and attachments block sizes, except instead of letting the user set the size set them to 2/3 and 1/3 of the current window size respectively. Thanks,
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
The attached offending e-mail was a result of importing from outlook. The two support e-mails are duplicates with the "To:" list corrected, to help prove the point.
*** Bug 192559 has been marked as a duplicate of this bug. ***
Flags: blocking1.3?
We started using mozilla on HPUX 10.20 with 0.9.4 and the only thing left to convince us to switch all hp-ux workstation user over (around 120) is the quite unusable mail client. Although it is slow, this bug makes it really unusable as the resizing of the panel takes around 2-8 seconds to complete. As we have a lot of long email_aliases and long names about every mail with attachment leads to that problem. So from my point of view (although very biased of course, through bad experience) this should be a blocker for 1.3
Flags: blocking1.3? → blocking1.3-
*** Bug 196132 has been marked as a duplicate of this bug. ***
(Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030210) I don't know if this is the correct bug to make this note, but this isn't limited to mail and news. This behavior will occur anywhere in the browser. From what I can tell, Mozilla is sizing its GUI content to the wrong width in certain situations where it thinks its window is larger than it is. The right scrollbar needs to be locked to the right edge of the window but it's actually locked to the right side of the GUI content in some cases... Another way to reproduce this: 1) Install the pref bar (http://www.xulplanet.com/downloads/prefbar/) 2) Open the pref bar's "Customize" panel and start adding buttons to it until the buttons go off the right side of the window 3) Edit the label of one of the buttons currently on the pref bar 4) Hit "OK" and notice your right vertical scroll bar has gone bye-bye If you then resize the window so that the entire contents of the pref bar fit, the scroll bar comes back. The scroll bar hasn't actually gone anywhere, it's just Mozilla has gotten confused about the size of the window, and has scrolled the scroll bar right off the window. Restarting the browser will fix this for a while--meaning the scroll bar will be in the correct place even if the pref bar contents are clipped off the right side of the window. Might be a bug in the pref toolbar, but it seems to me Mozilla simply gets confused about where the edge of the window is. (This also affects the toolbar with the throbber as was mentioned in comment 9.) From what I can tell, this occurs if at any time any aspect of the Mozilla GUI (e.g., the menu bar, any of the toolbars, etc.) is assigned a width that differs from the width of the window.
Sorry if this is already known (I read most of the comments for this bug, but seriously, there is more than 18 months worth of discussion here!). A very long header field (e.g. Cc:), combined with an attachment, cause the whole mail pane to expand slightly (the section of the mail application that contains the list of messages in the current folder, the header and the message content). The list of folders on the left of the Mozilla Mail window is shrunk to compensate the expansion of the message pane. This is particularly noticable when stepping from one message to the next, because the Mozilla window "shakes" before settling on the new size. It's very disconcerting, although no functionality is lost.
Window size jumping all over the place when reading messages... I just came across this in Moz 1.3 (windows & Linux), I thought it was a MAJOR bug until I realised it was only one message in the inbox causing a problem. The from field had : NAV for Microsoft Exchange-CRO+AF8-EXC+AF8-02 <NAVMSE-CRO_EXC_02@Crocus.co.uk> Could we not allow a line break before the <NAV... bit ?
okay everyone, I am going NUTS with this one. It's nothing like any images on this thread, but I've been coping with this fault for a couple of months now, and I tried looking at every option, every bugzilla thread, and found nothing. Whenever I open a message, I don't see the standard header you all do (like a bar with the address, subject and an attachments windows if there are any - in fact, this is the bad part). see a screenshot here taken with mozilla 1.3 - it will speak better than many words http://www.studiowares.com.br/cyx/other/images/mozillamail_noheader.png the message showing on the mozilla mail window has an attachment called "meditar.pps", and I can't save it at all - not even going to File, Attachment, Save all - it tries to save the file with no name, and when you give it a name, it fails. I sent the same message to another mail account and download it with a new profile, everything looked fine. Tried deleting prefs.js, XUL.mfl, all to no avail. When I created a new profile and tested, everything was how it should be. However the message display doesn't actually look like a bug. Is there an option to make it look like mine? Where the hell is it? How the hell did I turn it on, since I never wanted to? So I am posting this here, someone else could be experiencing it.
In response to #250's comment's, apparently deleting your addressbook files solves the wierd non-xul header problem you are seeing in your screenshot. One of our users was experiencing the same problem and there's a bug logged somewhere in bugzilla's bowels which you may be able to find referring to this issue.
I'm now using Mozilla 1.3 final and this bug shows up all the time as I try and debug installation of a new MTA for site. In doing so I want to see all the mail headers and so choose: View->Headers->All After that, whenever the message pane is viewing the expanded headers, it's very easy to lose the scroll bar on the message pane and thus render it useless until one either collapses the headers or moves to a new message. Interestingly the headers rendered on the gray background seem not to be truncated enough to allow for the existence of a scroll bar. It looks like the only place a scroll bar would be allowed is in the message body which would explain why once the headers become large, you lose the body and the ability to view it.
Something very much like this happens with my Mozilla 1.3 mail client. The message text on certain messages either isn't displayed ever, or after 1st viewing , vanishes. Any scroll bars vanish as does (most of) the attachment window. I am running Linux Mandrake 9.1 on an Athlon 1 GHz box.
Indeed, deleting abook.mab makes the attachment window appear again. Moreover, by deleting garbage characters from the end of the old abook.mab worked too, retaining all of my address book entries.
Since I upgraded to Mozilla 1.3, I cannot view the all headers with View -> Headers -> All because of the symptom described in this bug. The only difference is it happens for all the messages. (Because of the spam detection software, all the messages I receive have many headers.) I am using Mozilla on Windows 98 SE Japanese.
*** Bug 203766 has been marked as a duplicate of this bug. ***
My description for this problems is: When an e-mail is send to multiple people separated with only a semicolon, the mail program tries to put them in 1 line on the screen. This causes the columns of the Date, Status, Size, etc. to disappear. Also the tree at the left is resized to a small unreadable space. The tree is not resizable anymore. For some reason the long "To: someone@somemail.com;someoneelse@somemail.com;etc@somemail.com" is not broken into several lines.
I thought email addresses had to be comma separated. Anyone got an RFC?
Comma is mandatory: RFC822: 4. MESSAGE SPECIFICATION 4.1. SYNTAX [...] destination = "To" ":" 1#address ; Primary and: 2.7. #RULE: LISTS A construct "#" is defined, similar to "*", as follows: <l>#<m>element indicating at least <l> and at most <m> elements, each separated by one or more commas (",").
*** Bug 207141 has been marked as a duplicate of this bug. ***
RESCUE METHOD TO RETRIEVE ATTACHEMENTS The conditions which involve the disappearance of the attached files are unknown to me and I undergone them. But, while seeking a little, I found a method to recover them without another tools that the mail of Mozilla itself. 2 files seem, by miracle, intact for both the user and the local files, they are the Templates and Drafts folders. Just carry out a copy (not a move for security) of the mail in one of these folders (use Drag and Drop with the control key pressed). Then open the mail in an independent window (double click on it's name). Your mail is open, like for Edit it, and your documents will appear in the window of the attachements. When the mouse passes on the name of a document its temporary storage location appears in a bubble-info (usually C:\WINDOWS\TEMP with a name like nsmail.ext - nsmail can be suffixed with minus and a serial number if there is many attached documents with the same extension). You can now recover the documents.
RESCUE METHOD TO RETRIEVE ATTACHEMENTS (more simple) Just right click in the mail and select 'Edit as new...'. The mail is now opened in an independent window like for Edit it, and your documents will appear in the window of the attachements. When the mouse passes on the name of a document its temporary storage location appears in a bubble-info (usually C:\WINDOWS\TEMP with a name like nsmail.ext - nsmail can be suffixed with minus and a serial number if there is many attached documents with the same extension). You can now recover the documents.
*** Bug 210600 has been marked as a duplicate of this bug. ***
*** Bug 172924 has been marked as a duplicate of this bug. ***
*** Bug 210665 has been marked as a duplicate of this bug. ***
Modifying Subject because this bug has morphed: OLD: Long strings in mail or news header cause scroll bars and attachment window to disappear, making message unreadable NEW: Long Strings in Mail/News Header causes Folder Pane to Resize and/or Jiggle
Darn, forgot to actually CHANGE the Subject. Sorry for bugspam. :-[
Summary: Long strings in mail or news header cause scroll bars and attachment window to disappear, making message unreadable → Long Strings in Mail/News Header causes Folder Pane to Resize and/or Jiggle
I don't agree that the new subject captures the essence of this problem, at least from my own experience (bug 210600). I see three things as happening here: 1) Long Strings in Mail/News Header causes MESSAGE (not folder) Pane to Resize (not sure about the jiggling); 2) Resizing of message pane causes resizing of other panes; 3) Resizing of message pane, if this pane becomes too wide to fit on the screen, causes scroll bars and attachment window to disappear, making message unreadable. In this case I don't even get a horizontal scrollbar, in any of the many affected panes. This is a separate bug - maybe bug 151831 or similar. Fixing this issue would go a long way to mitigating the seriousness of the main bug as the message would then be readable if only with horizontal scrolling.
peter.r.kirk@ntlworld.com wrote: > I don't agree that the new subject captures the essence of this problem, at > least from my own experience I'll second this statement. While the folder pane does sometimes get squished to the point of unreadability, the biggest problems that are *due to the header pane* are: 1. long header strings, even when they have spaces, overflow the right edge of the header pane (note: the patch that made it possible to copy header text also made it possible to scroll individual header lines, but it's not at all obvious to the user that it can now be done) 2. messages with many headers, e.g. from list management software, overflow the header pane *vertically*, making the message body below and/or the folder contents above too small to use; any remaining headers that fall off the bottom are also inaccessible I run at 1600x1200 with Mozilla full-screen, and see these problems daily. The bugs could be mitigated, at least for people who can manage with a smaller font, by allowing the font size in the header pane (all of the panes, preferably) to be customizable, as it is in the message body. But that wouldn't fix them, just reduce the number of messages triggering them. Maybe there are actually two bugs here, and not all of the bugs marked as duplicates really are? That might explain why the bug seems to have morphed even though the originally-reported problems are still there.
I see the problem on a lot of mails with short Subject and short Filenames in the attachment field and usually a few moderately long entries in the To: section, e.g: Michaela Angermann <michaela.angermann@pumuckl.de> It seems to be related to the automatic change in size of the Mail Pane. A workaround for users would be to collapse the whole header. But thats not nice. It is especially annoying when scrolling thru the mail index: On my slow machine it takes 3 seconds to calm down entering or leaving a problematic message.
*** Bug 211496 has been marked as a duplicate of this bug. ***
I get this too, but in my case its inexplicable. There is violent jiggling of the inbox folder view in Mozilla Mail client and eventually this process ends up haning my PC and taking up 100% of cpu usage. The only option is then to hardboot. I have noted this fault in both Windows Xp and W2k03. It happens when the mail box is full, when it is empty, when I have just recieved mail or when there is no new mail. There is no direct pattern to it. It is no longer possible for me to use Mozilla mail at this time. It worked in 1.3, but 1.4 has broken it. Q
This happens to me also, or very similar. For no reason whatsover (well for no pattern) opening mozilla mail will cause the inbox view to vibrate violently back and forth. It happens when I just launch mozilla mail, when I just recieved mail, when I have no new mail, when my mailbox is empty and when its full. As I said it appears completely random. I am no longer able to use Mozilla mail at this time. Q
I agree with the final part of comment 269. The bug reported in comments 272 and 273 seems quite different from what I am seeing. George sees vibration of windows at random times even displaying an empty mailbox. I see different symptoms in different circumstances: stable resizing of windows, with no vibration, when I click on mail with specific properties, extra long recipient fields. These must be different bugs. I hope this bug isn't becoming a dumping ground for miscellaneous display problems which annoy lots of people but look hard to fix.
Can I just get a clarification - Peter Kirk, comment 274 - in the attachment you just sent, the first 9 toolbar icons are distorted.. it looks like it is probably due to mapping down to 16 colours, and the next - print - is almost completely missing, and the stop icon is gone. Is that simply due to the gif attachment being reduced down to 256 colours (or maybe 16, and then saved as a 256 colour gif), and are the missing stop and print icons related to the same problem, or is that really what you see on your screen when the problem occurs ? Also, it looks as if you have large fonts (120dpi) enabled in windows - is that correct ?
Some of the distortion is indeed due to reducing this to a GIF. I can send the full BMP privately if you would like me to. But on my screen, ever since I enabled them, the Print icon has been mostly missing and the Stop icon completely absent. Another bug which I hadn't bothered to report yet. I have enlarged the text size because the default comes out unreadably small on my 1400x1250 laptop screen.
I've been trying to replicate this problem here and no matter what I do, I can't get it to fail any more. I'm running the 1.4 release, 1600x1200, normal font size, and I created a message in my inbox (using vi) with a 3800 character CC line all on one line. Viewing the document source verifies that it arrived at mozilla on on one line. Does the long line have to exist in a particular header for this problem to occur now ? I notice in the example Peter uploaded that it was a BCC line that was very long, so I assume he was looking at something in his Sent folder as a BCC line should not exist in an incoming email. Has anyone got an absolutely fool proof way of reproducing this problem right now in mozilla 1.4 ? It would probably pay to include screen res, font size, and what lines are in the header of the offending message.
The attached message causes the problem consistently for me, on my 1400x1050 screen (with enlarged characters, but I was getting the same problem with other messages when I had smaller characters). Of course in this case I have not given any place where the line could be broken, but with imported messages the lines are not broken even where there are spaces. This is perhaps because the entire lines including spaces are parsed as a single address - note the continuous underline under the address list in the screenshot. So perhaps two bugs, or features, are interacting and causing this problem: 1) lists of addresses on one line separated by commas are parsed as a single address; 2) single addresses longer than one line are not broken, even at spaces, but cause the window to expand in width without limit. I have noted other problems with the parsing of lists of addresses. The message shown in the previous attachment (with BCC's) had been imported from Outlook 2002, probably indeed from its Sent folder. But I get the same problem with To, CC and BCC lines.
I can confirm that the problem occurs for me with Peter's attachment, so it's not something specific to his configuration I can also confirm that if I edit the message I manually tweaked a couple of comments back (that previously caused no problem), and remove the commas and spaces from the addresses so that it becomes one huge long unbreakable line, then the problem does occur. So this bug seems to occur specifically when moz can't break the long line at whitespace. In Peter's case, it looks like there's a(nother) bug in the outlook importer that creates very long unbreakable lines.
Apologies for the bug spam, but I just noticed one more thing - while a problem message is displayed, the pane will resize back and forth whenever the mouse moves over (or leaves) the "Get Msgs" toolbar icon, or over a clickable link in the body of the displayed message (such as a mailto: link, an http: link, or something that moz thinks looks like an email address) This behaviour may help to explain why some people have been reporting sporadic resizing where they said they didn't do anything - they may have moved their mouse over something that triggered the redraw event.
On comment 281: I get this too. On comment 280: I edited my test message to insert spaces in the long address I typed in before, dividing it into separate "words". Mozilla has added commas between each word in the address, and some new lines, and now treats each word as a separate address. The commas are already there in the source in "unsent messages" and so were presumably added when I pressed "send later". But even when I edited the mailbox file to remove the added commas and new lines, closed Mozilla, deleted the .msf file and reopened, the address line is still parsed as multiple addresses and broken between these addresses; obviously a space in an address line is considered a separator and a line break possibility. So why isn't this happening with my messages imported from Outlook? The long address line here includes many spaces but it is parsed as one long address line. They are real spaces, not hard spaces. The line in the source consists of a number of items mostly in the format "John Doe (johndoe@isp.com);" but Mozilla displays only "johndoe@isp.com". Some items are in the format "John Doe (John Doe);"; Mozilla displays just "John Doe", but does not split at this space. Well, I see that's not the full story. I did a test from which I see the following result from parsing: Line in the source (I really changed real names to all x's to protect privacy): BCC: xxx xxxxxxxxxxxxxx (xxx_xxxxx@xxx.xxx); xxx xxxxxxx (xxxxxxxxxx@netscape.net); xxxxxx & xxxxxxxx xxxxx (xxxxxx@xxxxxxx.xxx) Display as single, unwrappable e-mail address (recreated as I couldn't copy this line - all with a continuous underline): Bcc: xxx_xxxxx@xxx.xxx xxxxxxxxxx@netscape.net xxxxxx@xxxxxxx.xxx <xxx xxxxxxxxxxxxxx ; xxx xxxxxxx ; xxxxxx & xxxxxxxx xxxxx> When I edit out of the source line all the parentheses, the source line is now parsed so that each space separates a new address. From some further testing, it appears that the presence on an address line of just pair of parentheses, as long as they contain at least one non-space character, is enough to trigger a different line parsing mode in which only commas, not spaces, are recognised as address separators. This may be sensible, but unfortunately it conflicts with the results of importing from Outlook, which include parentheses, but use semicolons, not commas, to separate addresses. Proposed patch, which will very simply solve the worst of this bug (though not the problem with window resizing when a single address is REALLY too long to fit in the window): edit the routine which parses addresses containing parentheses so that it recognises semicolon as well as comma as an address separator.
This is NOT the same bug as I reported and was marked as a duplicate. I just want to see ALL headers without truncation.
Reading the comments shows that there are many diverse symptoms: - scrollbars getting truncated (pushed outside the window so they are invisible) - various parts of text ditto, especially long headers - message body and message/thread list getting squashed vertically by header pane to the point where they become invisible or unusably small - folder list getting squashed horizontally to the point of unusability - maniacal pane jiggling as a result of resize and more. The only thing in common with these is that they are all related to the header pane automatically resizing. These symptoms have been around since before 1.0, so clearly getting resizing to work correctly in all cases is a very hard problem. Is it not possible to define a maximum limit on the pane size, both vertically and horizonally, and then use vertical and horizontal scrollbars on the header pane when it would exceed that? I'm submitting an attachment showing two of these problems: - long Received (and other) headers truncated at edge of pane - numerous headers causing header pane to resize so large that it wiped out the body of the message below
Ignore the low-res blurred fonts, I did that to keep the file size small. Symptoms are plainly visible despite this.
I have recently installed Mozilla V1.4 running on Windows-XP and now have this jiggle problem. I tried to reinstall V 1.3 from the net but that failed. So now it's V1.4 with the jiggle or change product :-(
Hi folks Just letting you know that bug 131733 may be related - probably in part a dupe of this, bug 201379 and bug 201460 but not entirely. A quick suggestion, though: At least for handling ultra-long subject (and From: address, these cause the same problem) lines, perhaps a truncated header and a tooltip would be the way to go? "Bob ... <bob@ ...>" with a tooltip that displays the rest? This is fairly common UI behaviour in many apps now, so it shouldn't confuse users too much. Surely not as much as the message pane going nuts!
What's important is that determining the size of the strings being displayed should not (or at least should have an option so it does not) attempt to resize it's container widget. It puts up vertical or horizontal scrollbars, and that's it. The only way "jittering" should occur is if the container is physically too small to display a sub-window of XxY characters AND one to two scrollbars. Then it grows to that absolute minimum size, puts up the scrollbars, and sits there. I personally don't like tooltips because they're frequently miscoded and avoid the issue. Miscoding: they're often unaware that their width, plus starting coordinate wrap off the visible area of the display. Problem Avoidance: they don't deal with the fact that the string could be so long as to wrap from monitor's left-most coordinate to right-most, yet cannot display the whole string. "Oh, it cannot happen." Yes, it can, and that's why you use tooltips for messages whose length you can control, whose value no-one would want to select-copy. Just my $0.02.
I can definitely see your argument about tooltips - however, what alternatives are there to display over-size strings? Scrolling fields are very clumsy, fields that wrap cause other problems (pushing the message body off the bottom of the screen), and just truncating the contents isn't really an option. A tooltip that's smart enough to wrap may be the best of a bad lot. The ideal solution, of course, is REASONABLE HEADER LENGTHS... but that's a lost hope. One alternative that'll help with only-just oversize headers is reducing the font size. That has its own implications on the accessability front, of course.
Of course, the *real* solution to this bug is to fix bug 9942.
Just a comment about a smart tooltip that knows how to wrap itself.. I agree that it avoids the problem of being wider that the desktop width, but in doing so, it creates a new problem where it could potentiallly be taller than the desktop height. It may be very unlikely that the contents of a tooltip cause it to fill the screen entirely, but it's possible that the top left position of the tooltip may be sufficiently low down on the screen that the tooltip is partially hidden off the bottom of the desktop. Just my 2c.
Attached image A Long Message Header
On the other hand, here is a long message header. I can't snapshot it, but I can select the text of "Subject" with the mouse, and assuming I move the mouse to the right, force a scroll-right until the remainder of the field is visible. Now given that this is doable, What's the harm in two buttons, [<] and [>], appearing on the left and right-hand side of that view-only field to indicate that scroll-left/scroll-right is possible? You still manage to keep the whole thing in one line... Tooltips to me are extremely annoying when used for anything other than help or advisory messages: if they have something important in them, and I'd want to select/copy it's text, forget it... They're often anchored at the wrong place, so their text "falls off" the edge of the screen, and the disappear when you don't want them to. So I advise against them.
Attached image A Long Message Header
On the other hand, here is a long message header. I can't snapshot it, but I can select the text of "Subject" with the mouse, and assuming I move the mouse to the right, force a scroll-right until the remainder of the field is visible. Now given that this is doable, What's the harm in two buttons, [<] and [>], appearing on the left and right-hand side of that view-only field to indicate that scroll-left/scroll-right is possible? You still manage to keep the whole thing in one line... Tooltips to me are extremely annoying when used for anything other than help or advisory messages: if they have something important in them, and I'd want to select/copy it's text, forget it... They're often anchored at the wrong place, so their text "falls off" the edge of the screen, and the disappear when you don't want them to. So I advise against them.
I was just about to file abou the same bug, when I saw this. Just compiled 1.5 from source (on Gentoo linux) and doing experiments on bug #222826 (not related here) I found out the weird auto resize bug. Just to say, 1.5 still has it.
*** Bug 191238 has been marked as a duplicate of this bug. ***
Upgraded from 1.3 to 1.4 a month ago and saw the jitter problem for the first time today. But it was not related to the length of any headers. It was caused when the selected folder was at a boundary condition on the need for the scrollbar in the pane listing folder contents. If it is right at the point where the list of messages will just barely fit/not fit in the pane, Mozilla can't make up its mind whether to display the scrollbar or not, and jiggles rapidly adding/removing it. Folders which clearly do/don't require the scrollbar to appear don't trigger the behavior. I can turn this on and off quite reliably by selecting folders that have just the right number of messages to match the size of folder pane I have set (in my case at the moment, 13-14), or by adjusting the dividing line slightly. Note that this behavior is entirely separate from the bug where messages with many headers obliterate the message body pane, with no vertical scrollbar on the header pane even when they don't all fit.
Note also that the behaviour described in comment 296 is entirely separate from the bug described in my comment 282 and earlier. I saw no jittering, just stable resizing. So there are at least three distinct bugs here.
It occurs to me that the appearance/disappearance of the scrollbar in the message list pane, described in my comment #296, could have been caused by the header pane resizing so that the list pane alternately shrank and expanded very slightly; I had been thinking of it as the other way around at the time. Yet it happened reliably and only when I selected folders which were right at the hairy edge of scrollbardom; it didn't matter which message I displayed from those folders, though I had full header display on at the time. It seems to be the same problem described in 201460. Perhaps the header pane *always* resizes to fit the headers it's trying to display, but much of the time the shift is too subtle to notice? There is overlap between this bug (91662) and several others, e.g. 188138 and 131733. It seems as though, if automatic header-pane resizing simply didn't happen, an awful lot of the problems described in many threads would have no trigger.
*** Bug 227879 has been marked as a duplicate of this bug. ***
*** Bug 228778 has been marked as a duplicate of this bug. ***
Attachment #97874 - Attachment description: patch, also works with keywords → patch, also works with keywords [checked in: Comment #206]
Attachment #97874 - Attachment is obsolete: true
Comment on attachment 76566 [details] Image of my mozilla mail window with the formatting broken. This part of the bug is already fixed.
Attachment #76566 - Attachment is obsolete: true
Comment on attachment 76567 [details] A message in the same list which doesn't have an attachment. This part of the bug is already fixed.
Attachment #76567 - Attachment is obsolete: true
Comment on attachment 80749 [details] Better screenshot of this bug showing also desktop as reference This part of the bug is already fixed.
Attachment #80749 - Attachment is obsolete: true
Comment on attachment 85402 [details] the vertical splitter crossing the scrollbar of the mail folder listbox This part of the bug is already fixed.
Attachment #85402 - Attachment is obsolete: true
Comment on attachment 85403 [details] a screenshot of this bug under windows 98 This part of the bug is already fixed.
Attachment #85403 - Attachment is obsolete: true
Comment on attachment 96619 [details] screen shot of an email with a long subject, and an attachment. This part of the bug is already fixed.
Attachment #96619 - Attachment is obsolete: true
Comment on attachment 43017 [details] make a local folder with this email to see the problem This part of the bug is already fixed.
Attachment #43017 - Attachment is obsolete: true
Comment on attachment 43102 [details] better test case This part of the bug is already fixed.
Comment on attachment 43102 [details] better test case This part of the bug is already fixed.
Attachment #43102 - Attachment is obsolete: true
Comment on attachment 63515 [details] [diff] [review] 62514 broke collapsed headers, sorry This part of the bug is already fixed.
Attachment #63515 - Attachment is obsolete: true
Comment on attachment 89053 [details] [diff] [review] Revised email address patch This part of the bug is already fixed.
Attachment #89053 - Attachment is obsolete: true
After trying to strike out obsolete comments on my printout, I found that I was too fast in marking attachments 43102 and 89053 as obsolete. I'll undo that. But a new idea: Would it perhaps be better to convert the whole hbox expandedHeaders to a grid like collapsedHeaderView? That would also close Bug 126071 forever, which still needs a patch from time to time.
Attachment #43102 - Attachment is obsolete: false
Attachment #89053 - Attachment is obsolete: false
Sorry, It seems I now deleted the URL...
*** Bug 240263 has been marked as a duplicate of this bug. ***
I'll try to take a stab at this. I think we're seeing 2 different bugs here at work. The fact that the splitter jiggles is strange. The whole purpose of the splitter is to allow the user to *set* the size, so it should stick with it. The "content" (i.e. the 2 sides of the splitter) should have no effect whatsoever on the position of the splitter or the container, just like the content of a window doesn't resize it. That the splitter changes at all (due to changes in the content) is a bug in the XUL splitter implementation for me, not a Mailnews bug, and I filed bug 241253 about that. Thanks to a hint from Neil Parkway, I noticed that the fix by Stefan Borggraefe for bug 63654 also fixes this part of the bug. In my tests, the splitter remains unchanged regardless of the header bar content. The other part of the bug is still left: Long addresses, esp. with attachment box, extend the thread pane and msg pane bejond the egde of the window, making the right side invisible.
Assignee: sspitzer → ben.bucksch
Status: REOPENED → NEW
I may have seen this same behavior with the Google regular search. I used the advanced search, but when the results are returned, there is an entry field at the top of the page for another query. If I use that, I get a screen that jiggles.
*** Bug 244262 has been marked as a duplicate of this bug. ***
s/Neil Parkway/Neil Rashbrook/ The mentioned fix for bug 63654 is now checked in, fixing most of this bug, too. > The other part of the bug is still left: Long addresses, esp. with attachment > box, extend the thread pane and msg pane bejond the egde of the window, making > the right side invisible. This remains true. Because this bug is such a total unreadable mess (it took me a whole working day just to read over it! :( ), I filed a new bug about that: bug 247833. I'll dup this bug against that. I'll comment here once that bug is fixed, to notify people who are cced here. Also compare bug 9942. *** This bug has been marked as a duplicate of 247833 ***
Status: NEW → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
No longer blocks: 176238
Product: Browser → Seamonkey
No longer blocks: 158464
No longer blocks: majorbugs
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: