Closed Bug 8181 Opened 25 years ago Closed 25 years ago

[PP] Windows line breaks cause problem for Mac 5.0 mail viewing

Categories

(MailNews Core :: Backend, defect, P3)

Product:
MailNews Core
Component:
Backend
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: momoi, Assigned: rhp)

References

(
URL
)

Details

Attachments

(2 files)

macintosh screen shot in gif
22.88 KB, application/octet-stream
Details
macintosh screen shot in gif for .eml
14.12 KB, application/octet-stream
Details 
** Observed with 6/14/99 Mac build **

The above URL contains I18n smoketest file containing 5 msgs,
Latin 1, Japanese and UTF8 messages.

This was created by a Windows client.
Mac messenger 5.0 has a problem with Windows line breaks
apparently and I am not able to display Message pane header and
body correctly -- for the header, I see nothing for most of the
messages and for the body I see RFC 822 text type display.
The view pane display does work.
When I converted the smoketest file into Mac type line breaks,
all the Message headers and body text showed correctly.
OS: Windows NT → Mac System 8.5
Hardware: PC → Macintosh
Corrected the paltform & OS to Mac.
I want to add that one of the 5 smoketest msgs is mail with
an attachment. I was never able to load this message when I selected
it -- it kept on trying to load over and over again and it actually
froze the apprunner. There seems to be some sort of infinite
attempt at loading this particular message. When I changed the
line breaks type to the Mac one, I did not have this problem.
Assignee: phil → bienvenu
The message parser is supposed to be smart enough to accept any linebreak style.
If we've broken that, we should fix it. Reassigning to bienvenu.
Target Milestone: M8
No, this didn't work in 4.x either, I'm afraid. But there weren't any infinite
loops, AFAIK.
This was working before (I used the smoke test data to test my fix cross
platform on 6/9).
I don't see the infinite loop but it takes long time to process a message in the
smoke test which has an attachment.
I haven't changed the message parser in months. Is this a libmime problem?
Summary: Windows line breaks cause problem for Mac 5.0 mail viewing → [PP] Windows line breaks cause problem for Mac 5.0 mail viewing
cc'ing Rich - if this is really a problem with message display, as opposed to
database header parsing, he might have an idea.
I need some input from someone who has seen this problem - is it strictly a
message display problem, or is it a db header parsing problem? Does anyone need
more clarification about the difference?
I'm not sure on this one. Sounds like a possible problem with the smoketest
file on the Mac? These files need to be platform specific don't they? I don't
see where libmime would loop forever. It will hit the end of the buffer and
quit at that point.
About the mesage which causes attempts to load over and over again, it turns out to be the same message
which prompted me to file Bug 8899 for Windows client.
Oh, loading over and over was the problem we had with auto detection for
charset stuff. Could this be it?

- rhp
Attached file macintosh screen shot in gif — 

    
    

    
  
Could you try looking at the file tempMessage.eml in your temp directory
after loading a message and see if that looks OK, please? If that looks OK, then
the problem has nothing to do with the db header parsing.

    
    

    
  
This looks like the right message to me, which is all the DB can help with. I'm
not sure who's supposed to do the line conversions (i.e., the code that writes
out the message to the temp file, or the code that parses the message from the
temp file) but I'm not involved in either of those pieces of code. Anyone know
what the right thing to do is? Can someone run the version of 5.0 that actually
worked and see what kind of temp file was generated?

    
    

    
  
There is one differece I noticed when I compared the "tempMessage.eml"
generated for the Mac-type linebreak message as opposed to
Win-type linebreak for the same message. The .eml file for the latter
contained Unix-type "LF" rather than the Mac-type LF.

    
    

    
  
I didn't mean to write "Mac-type LF". It should have been "Mac-type CR"
rather.

    
    

    
  
thanks for the clarification, but I would expect the windows lines to end with
CRLF, not just LF.

    
    

    
  
The editor I'm using on my Mac can detect all 3 types of line breaks.
This is what my editor tells me:

Smoketest file for Mac-type: CR
 .eml file generated from this: CR

Smoketest file for Win-tyep: CR+LF
 .eml file generated from this: LF

The Linebreak detection on my editor is pretty accurate and
so from the Win-type Smoketest file, we are indeed generating
LF-type .eml file

    
  
Target Milestone: M8 → M9

    
    

    
  
I don't think this is my bug, but in any case, I'm not going to get to it by m8

    
  
Assignee: bienvenu → rhp

    
    

    
  
Sorry, Rich. I don't know who's bug this is, or if it really is a bug, but I'm
not doing the bug any favors by leaving it on my list. It could be that libmime
needs to deal with non-native line termination.

    
  
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE

    
    

    
  
I'm pretty sure this is the same problem issue for Bug #9231. Marking as
duplicate.

- rhp

*** This bug has been marked as a duplicate of 9231 ***

    
  
QA Contact: lchiang → momoi

    
    

    
  
Kat - since you filed this, I'll let you verify/agree that it's a duplicate of
the other bug (which was actually reported later than this one :-)

    
    

    
  
From the description of 9231 alone, I'm not sure if this bug is a
duplicate of that one. Since manifestations of a backend fix can be
extensive,  I'm inclined to monitor 9231's fix status and check on
this one when that one gets fixed. I'll hold off verifying this bug until
9231 is fixed.

    
  
Status: RESOLVED → REOPENED

    
  
Resolution: DUPLICATE → ---

    
    

    
  
** re-checked with 7/22/99 Mac build **

Bug 9231 has been verified/wroksforme since 7/7/99.
On today's Mac build, the problem described in this bug
still exists. This is proof enough that it is not
the same bug as Bug 9231.

Re-opning it...

    
    

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

    
  
Target Milestone: M9 → M10

    
    

    
  
Hello all,
I have no clue on this one...nothing with respect to parsing line breaks has
changed with libmime so I can't see how this "worked" and then stopped working
at some point.

mscott:
Could something have changed with how we write out the tempMessage.eml file
along the way?

davidb:
This didn't work with 4.5, correct? I have a feeling that we were making it
work in the tempMessage.eml creation and that may have changed and now it
doesn't work.

Comments welcome!

In either case, this is getting bumped.

- rhp

    
    

    
  
I don't believe it worked in 4.x. Is anybody claiming that it did?

    
    

    
  
They are claiming it worked in 5.0, but since libmime parsing is the 4.x code
base, it is relavent.

- rhp

    
    

    
  
I don't think it's very relevant that it worked in 5.0 - that may just have been
a bug, right? What's really relevant is whether libmime handled non-native line
breaks in 4.x. If it hasn't, I can't see a lot of reason to try to change it
when we have so many other things to do to get to parity with 4.5

    
  
Status: REOPENED → ASSIGNED
Target Milestone: M10 → M12

    
    

    
  
I go back to my original comment posted 06/28/99. Isn't this a restriction
that we placed on these files? If this file would break 4.x, then I'm not going
out of my way to fix this one. Sorry, but I (like everyone else in the world)
has a billion things to do to get anywhere close to the 4.x feature set.

If I try to do something here, it will be post B1.

- rhp

    
    

    
  
I concede that the same problem existed on Mac under 4.x --
though Windows client has no problem reading Mac mailboxes.
I think it would be nice if direct interchange of mailbox files
between different platforms can be done under 5.0. That's why
I filed this bug.

More important to me would be that our migration/import mailbox
utility be able to handle linebreaks when migration occurs from
one platform type to another.
If this can be accomplished during 5.0, that would be wonderful.

    
  
Blocks: 11091

    
    

    
  
(target milestone is M11 or M12 - add to mail beta tracking bug)

    
  
Target Milestone: M12 → M13

    
    

    
  
Just tweaking the milestone.

- rhp

    
  
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME

    
    

    
  
I'm sure a LOT has changed since this was originally posted (and it was
probably fixed along the way), but I copied over my PC formatted smoketest file
to the mac and everything seemed to work fine.

- rhp

    
  
Status: RESOLVED → VERIFIED

    
    

    
  
** Checked with 12/17/99 Mac PPC M12 build **

With the above build, I don't have any problem displaying msgs
in the PC version of Smoketest file which contains both CR+LF.

Mac had this problem throughout 4.x cycles and so this is indeed
a very good change.

Marking it verified/fixed.
Product: MailNews → Core
Product: Core → MailNews Core

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: