Closed Bug 538892 Opened 15 years ago Closed 14 years ago

Replying to or forwarding emails on Hotmail no longer works properly: message content is often lost

Categories

(Tech Evangelism Graveyard :: English US, defect)

Product:
Tech Evangelism Graveyard
Component:
English US
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking2.0 -, status1.9.2 wanted)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- -
status1.9.2 --- wanted

People

(Reporter: dhgutteridge, Unassigned)

References

(
URL
)

Details

(Keywords: common-issue+, regression, Whiteboard: [qa-revisit-2010-05-30])

Attachments

(6 files)

Failing message text
3.13 KB, text/plain
Details
Screen shot of failed response state
266.03 KB, image/tiff
Details
My hotmail no fwd screenshot
125.05 KB, image/png
Details
Difference between what Hotmail sends 3.5 and non-3.5 UAs
602.87 KB, text/plain
Details
Screen shot of ff3:true setting with failed response state
444.06 KB, image/tiff
Details
Compressed tar-file comtaining the mentioned logs
1.99 MB, application/octet-stream
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100105 Firefox/3.6
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100105 Firefox/3.6

Since I started using the 3.6 release candidate yesterday, I've been experiencing problems using Hotmail.  When I try to reply to or forward a message, no content appears in the message window, and there's no cursor focus in the window either.  This happens about 90% of the time.  For whatever reason, occasionally things do work correctly, but those instances are few and far between.

I apologize if this has already been reported here.  I did try various combinations of searches for it, but I couldn't see anything referencing "Hotmail" against 3.6 at all.  I didn't have this problem with the 3.5 series.  I did see an external reference to someone with the same problem, see here:

http://groups.google.com/group/mozilla.feedback.firefox/browse_thread/thread/7a70d2601001e92f

Reproducible: Sometimes

Steps to Reproduce:
1. Log into Hotmail.
2. Respond to an email.
3. See there's no message text quoted in the response.
Actual Results:  
No message text (no content at all) in the message window.  No cursor focus.

Expected Results:  
Message text in the window.  Cursor focus present.
Version: unspecified → 3.6 Branch
I don't know if this has any relevance, but when I try to respond to an email, among the many warnings that appear in the Error Console is this one:

Warning: XUL box for span element contained an inline #text child, forcing all its children to be wrapped in a block.
Source File: http://sn113w.snt113.mail.live.com/mail/EditMessageLight.aspx?ReadMessageId=46a4463a-fe2a-11de-b838-00215ad9be3e&FolderID=00000000-0000-0000-0000-000000000001&CP=-1&n=117363019&Action=Reply&AllowUnsafe=False
Line: 0
This issue isn't restricted to Mac OS X.  I can duplicate it on NetBSD as well.  (I just built 3.6RC1 from source on NetBSD 5.99.22/amd64 and tested there.)

I should also note that this isn't seemingly caused by specific message content, as the problem randomly does and doesn't happen with the same email being replied to repeatedly, during the same session.

(I'm assuming this isn't an "evangelism" issue with Hotmail, but have no insights here.  And yes, I know Hotmail is very uncool, but I've never found a burning need to replace the original address I've had since 1998, and, oh, never mind...)

Dave
i confirm the bug repported by David H. Gutteridge.
i have exactelly the same problem and at 90%.
1 time on 10 i can see again the text when i answer or reply.
i confirm the bug repported by David H. Gutteridge.
i have exactelly the same problem and at 90%.
1 time on 10 i can't see again the text when i answer or reply.
i confirm the bug repported by David H. Gutteridge.
i have exactelly the same problem and at 90%.
1 time on 10 i can't see again the text when i answer or reply.
OS: Mac OS X → All
I can confirm this happening on OSX 10.6.2 and it started with FF 3.6

Clearing Cache is a temporary solution

Pretty annoying...should be fixed ASAP
no, not for me. i clear the cache every days but same problem.
the problem remains even when i launch firefox in safe mode.
almost same problem with yahoo mail.
when you reply, the cursor is invisible and you don't know where you write.

you must clear the cache each time, but if you want to reply a second time, same problem: the cursor disappear.
Confirming based on support requests
Status: UNCONFIRMED → NEW
Ever confirmed: true
According to a user reporting this problem in Live Chat, it only affects certain Hotmail accounts.  Logging into another Hotmail account in the same Firefox session results in replies and forwards working properly.
That only means it might be a new cookie/cache setup. Logging on as a new Hotmail user might be essentially the same as clearing the cache...which only works temporarily
WOOT, finally figured this damned thing out.  (Thank very patient users on support)

1) It only happens when you forward a RICH TEXT email with images in rich text mode.  So the easy workaround is to change to plain text mode from the compose toolbar.
2) It works fine if you just change your user agent back to 3.5.7

Which implies that Hotmail is trying to do something fancypants with 3.6 and it's not working if you are trying to include images.  Go figure.
The big problem is that the default Emailing for the greater good thing has an image so you may be seeing this with lots more email than you would think.
Re. comment 13, changing my user agent back to 3.5.7 has no effect in my case, with either of the accounts I tried.

I find that when I log in, typically the first email I try to reply to or forward works fine, regardless of the content.  Every subsequent email is a problem, just about.  (And going back and retrying the first message that worked fine yields the problem.)
Adding to comment 15: when replying or forwarding *does* work, emails using rich text and including images are handled correctly.  And responding to emails in plain text likewise stops working just the same as everything else.  What fixes it is repeated logging out and back in after clearing my cache, as others have remarked.  Hardly very practical for typical use, unfortunately.
and oh yeah....works fine in Safari ;)
I just tried this out on an old machine I have running Windows 2000.  Firefox 3.6 works pretty much perfectly with those same Hotmail accounts, without needing any cache clearing, user agent tinkering, or anything else.  I tested with around forty emails, and only two exhibited the problem.  Repeating the test with the few problem emails yielded correct content in the edit box.

Retesting on NetBSD, on the other hand, exhibited the very same problems I'm seeing on Mac OS X.  Changing the user agent didn't make a difference, neither did replying with plain text.  Clearing the cache did.  Once the content disappeared from the edit box, it would never work again on subsequent messages without clearing cache.

So it appears with the same Hotmail account, a stock Firefox 3.6 (I had no add-ins/extensions/whatever installed on any of these) will exhibit this problem to varying degrees depending on the OS it's running on.
Weird, I'm finding it 100% reproducible on OSX with the 3.6 useragent (after clearing caches even) but 100% not reproducible with the 3.5.7 useragent.
FWIW, if you change user agent, you should always clear cache to make sure you're not caching possibly bad code.  The question is if you change user agent and clear cache if it still breaks again.
stop the **** guys.

there's a bug with the 3.6 version, the mozilla team is aware about this and they will fix it in their next update.
so stop the bla bla bla!
unless you have time to lost.

no need to say 10 times the same thing.
FWIW, as far as I know, no one here knows anything more than what's in this bug.  I've called someone I know at Microsoft to get them to help us figure out what's going on.  There's no fix planned for the next release of Firefox 3.6 because it doesn't seem to be something we can fix without help from Microsoft.  Please don't try to make it seem otherwise, frank DaSilva.
listen, the problem appear only with the 3.6 version and not before.
means it's the 3.6 the problem.
no problem with 3.5.7, IE neither.
Cww: I retried again (with cache clearing), and am getting the same results.  (I recorded a screen capture of my steps to show what I'm seeing, if anyone's interested.)

Frank DaSilva: All this back and forth can be part and parcel of isolating bugs.  Just because the problem appears starting with 3.6 doesn't necessarily mean the problem is with Firefox.  It could be that Hotmail has code that reacts differently depending on the browser ID string it receives, and for whatever reason it's not handling the value of "Firefox/3.6" properly (yet).  That's Cww's point; we're trying to isolate where the problem is.  His results imply the problem is with code on the Hotmail side not behaving properly, since (in his case) Firefox 3.6 works correctly if it pretends to be 3.5.7, from Hotmail's perspective.  Unfortunately, my results are conflicting with Cww's at the moment.  (But that still doesn't rule anything out.)
ok guys, fine.
me i'm not a wizard, neither a programmer.
i just run tests, that's all.

by the way, here again my post from the 3, cause the problem is not with hotmail only.

2010-02-03 15:43:06 PST

almost same problem with yahoo mail.
when you reply, the cursor is invisible and you don't know where you write.
you must clear the cache each time, but if you want to reply a second time,
same problem: the cursor disappear.
Ok, I have someone from Microsoft on the Hotmail team working on reproducing the problem.  As far as they can tell me, no one from their support team has escalated this so it's not something they see as very common (then again, they probably don't have many non-Windows users). I'll let you know when I hear back.  (It's a personal favor from a classmate, so I'm not going to get a run-around.)

The fact that it works on an older machine is really interesting.  Maybe it's some sort of race condition that is only apparent on faster machines?  (The browser code is the same across all Windows versions).  Does it work better if you wait (say 30 seconds after the page has completely finished loading) before trying to reply/forward?  What about waiting 30 seconds after clicking the reply/forward button before trying to type or interact with the page? 

I'm possibly wrong about the user agent because now that I'm being very deliberate about how I'm trying to reproduce this -- including watching my timing and which emails I choose to use, I can't reproduce it reliably at all even on 3.6 (it'll happen if I forward lots of emails but I can't reliably find steps to have it happen on the first email I click after a cache reset)

I'm going to wait to see if the Hotmail folks say anything.  Thanks for helping figure this out.
Ken Murray. New to Firefox 3.6. Using Win xp on laptop and Hotmail. I am having the same problem. However it does not happen on all emails. Unable to analize the difference.
Re. comment 26, it does seem like there's a timing issue involved, yes.  After the first message, if I quickly click "reply" or "forward", it never works.  If I wait a long time between opening the email I'm going to respond to and replying, it seems to work correctly every time.  I can reproduce this scenario on the same email over and over.  Each time a quick response doesn't work, but waiting a while does work.  By "a while" I mean more than thirty seconds, more like a few minutes.  (This suggests it's possible there's a link between cache clearing success and this "lengthy wait" method, like something is being reset after a certain amount of time.)
Here's the email I got from the hotmail team:

"I'm trying to hunt down a mac laptop to get a repro.  

Can we get the message source from one of the messages that is failing?  Also a screen shot of the entire firefox screen when they get a repro?

To get the message source:

1) login to hotmail
2) go to inbox
3) Right click on the message to get the context menu
4) Select View Message source
5) copy into notepad, save and send it to us"

You can attach the screenshot and the message source as attachments to this email.  But I'll also pass along your comment about timing.
Attached file Failing message text — 

    
    

    
  
Tom Eeles. I am having the same issue since upgrading to 3.6. Very annoying and big time waste. Possibly the reason Microsoft haven't got many people reporting this issue is because not many bother with their fairly inaccessible 'Help' portal. I have logged it here; 

http://windowslivehelp.com/community/p/221419/763719.aspx#763719

But none of the replies have been helpful. Perhaps you could link the two bugs so that there is official cross application work going on?

I can post an error message if you tell me how! I have it as screen shot bitmap.

Cheers,

Tom
Keywords: common-issue+

    
    

    
  
Hmmm... here, unless I do it in < 3 s it works.  Maybe it has something to do with your connection speed or extensions?

I can't link the two bugs, but I'll let the hotmail team know of the one you linked so they can figure it out.

    
    

    
  
Ok, I can definitely reproduce this if I route all my traffic through my cellular network and go somewhere with shoddy reception and click quickly.

    
    

    
  
I'm using LAN in my house, I'm in Pully, Switzerland. It doesn't happen in Internet explorer, just firefox...

    
    

    
  
Re. comment 33 and comment 34, the only extension I'm using is a dictionary add-on, and disabling it makes no difference (as I'd expect).  I'm on DSL broadband that can do about 600KB/sec.  I don't have any problem using an older Firefox release, or alternate browsers.  It's true in my case I haven't tested outside of my home networking setup, but it seems odd there'd be an interaction there that wouldn't affect other browsers, no?

    
    

    
  
No, Hotmail pushes different code for different browsers and different browsers may react differently when code isn't fully loaded.  I think in Firefox 3.6 we try to make the page more responsive earlier but that means you can click on something before the dependent code is loaded.

    
    

    
  
Hubby and I have our own Windows User Accounts on the same pc, both using Firefox 3.6 (I have more add-ons), and his Hotmail is having the issue, while mine is not.

    
    

    
  
Cww: in last week's meeting you said you suspected that this was JS related; why was that?

    
    

    
  
My contact at Microsoft was just curious if we'd made any JS changes they should know about that they may need to work around.

    
    

    
  
When the problem happens, do any errors show up in the Error Console?

    
    

    
  
Re. comment 41, no, I don't see any errors.  There are lots of warnings, but they seem to occur regardless of success or failure.

    
    

    
  
I wonder if someone from QA could try to help here...
Keywords: qawanted

    
    

    
  
tekw1960-comp@yahoo.com, does the problem appear for you if you restart firefox in "safe mode"?

    
    

    
  
Assigning to Tony to lock down reproduction steps - do we have any suspicion of what area of code is going wrong here? Sounds like DOM manipulation to me, but not sure how that squares with the intermittent presentation.
Assignee: nobody → tchung

    
    

    
  
So let me see if I understand the setup:

1)  The problem appears on BSD and Mac but not Windows.  No mention of Linux.
2)  The problem appears on 3.6.  No mention of m-c.
3)  The problem is related to submitting a form via POST.

Is that all correct?

If so, can someone who can reproduce the problem reliably either change their proxy settings ("Settings" button in the "Connection" section of Preferences > Advanced > Network) to "No Proxy" or install a current 3.6 branch nightly?  If either one (or better yet both) fixes the problem then this is similar to the various depencies of bug 547239.

If you try the above mitigation steps, please remember to either set the proxy settings back to the default value or install Firefox 3.6.2 when it comes out, depending on which you tried.  If you install a 3.6 branch nightly it will NOT auto-update to stable releases; you will remain on the branch nightly channel and not get updated from that branch when it reaches EOL.  So installing 3.6.2 is very important if you try the branch nightly on top of your normal install.  If you try the branch nightly in a separate install (which is pretty simple on both Mac and BSD), then the problem won't appear, of course.

    
    

    
  
Re. comment 46:

1) Other users have reported problems with Windows as well.  I can duplicate it occasionally under Windows, but it doesn't happen for me as frequently.
2) I'm not sure what "m-c" means?
3) Yes.

My proxy settings are always "No Proxy".  I downloaded the latest 3.6.2 build (March 16th) for Mac OS X and tested with it, and the problem still occurs for me.

    
    

    
  
(In reply to comment #47)

I can't repro on Windows and 3.6.

    
    

    
  
I'm sorry but I'm not sure what the solution is eventually for the disappearing text on 'reply' and 'forward'...I'm not technically literate so can somebody simply explain step by step what I need to do?? Many thanks to all!

    
    

    
  
(In reply to comment #46)
> So let me see if I understand the setup:
> 
> 1)  The problem appears on BSD and Mac but not Windows.  No mention of Linux.
> 2)  The problem appears on 3.6.  No mention of m-c.
> 3)  The problem is related to submitting a form via POST.
> 
> Is that all correct?
> 
> If so, can someone who can reproduce the problem reliably either change their
> proxy settings ("Settings" button in the "Connection" section of Preferences >
> Advanced > Network) to "No Proxy" or install a current 3.6 branch nightly?  If
> either one (or better yet both) fixes the problem then this is similar to the
> various depencies of bug 547239.
> 
> If you try the above mitigation steps, please remember to either set the proxy
> settings back to the default value or install Firefox 3.6.2 when it comes out,
> depending on which you tried.  If you install a 3.6 branch nightly it will NOT
> auto-update to stable releases; you will remain on the branch nightly channel
> and not get updated from that branch when it reaches EOL.  So installing 3.6.2
> is very important if you try the branch nightly on top of your normal install. 
> If you try the branch nightly in a separate install (which is pretty simple on
> both Mac and BSD), then the problem won't appear, of course.

Repros on trunk for me: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a4pre) Gecko/20100318 Minefield/3.7a4pre

Repro:
1) log into trunk build.
2) log into hotmail
3) select a rich text message and click forward
4) A drop down notification box says: "Please make sure you trust this unknown sender. Forwarding and replying will display any of the pictures and links that they included. This may allow them to send you more junk e-mail."   Click OK to proceed
5) Verify the next screen appears with blank body.  

Attaching screenshot.  I didnt even have to fake a lagging connection to repro this.  Need to try and find a regression range.

    
    

    
  
(In reply to comment #44)
> tekw1960-comp@yahoo.com, does the problem appear for you if you restart firefox
> in "safe mode"?

Problem was occurring with Windows XP. Sorry did not try 'safe mode'..but then it was happening in my hubby's profile, but NOT in mine when I logged in...so the setup of the pc was EXACTLY the same as far as software versions etc.

We had further issues with WinXP, and I have now upgraded to WIN7.

Would you believe it - I have just tested and, logged into my profile, I used Firefox and logged into his hotmail account and all worked perfectly! BUT, then I logged back into my hotmail account, and now it is giving the error - it when I click 'forward' on a message the content of the message disappears!!!!!

I have also just gone in and tested it on my son's pc - WINXP, Firefox 3.6, on the same profile, and the ORIGINAL problem is still there, ie for my hubby's login to hotmail, 'forward' gives you a blank email, and mine works perfectly!

So WINDOWS 7, Firefox 3.6 - Hubby's works, mine doesn't
WINDOWS XP, Firefox 3.6 - Hubby's doesn't work, mine does!
WINDOWS XP, Safe Mode - both accounts work.

    
    

    
  
I have the same problem AFTER installing Firefox 3.6.  NO OTHER CHANGES MADE.  I've been in the support business over 32 years and I can't believe the BS about it is someone else's bug other than version 3.6.  
This has been out here since January and no one has taken ownership of it! It is easily reproducable in the field - so why haven't we been able to get a fix for this!  
LOOK AT THE CODE THAT WAS CHANGED WITH 3.6!

    
    

    
  
(In reply to comment #44)
> tekw1960-comp@yahoo.com, does the problem appear for you if you restart firefox
> in "safe mode"?

The probelm appears on safe mode too.

    
    

    
  
A hotmail account is free and easy to set up. Since you seem to have trouble identifying the bug, can't you developers just sign up for an account and see it for yourselves?

And take all these "it works fine on..." comments with a pinch of salt - it is an intermittent bug so while it may seem to work fine, it may in fact just be you got lucky there.

Interestingly it seems to be happening on Opera version 10.10 as well but all the time rather than intermittently.

    
    

    
  
I have a fix. Use Internet explorer for hotmail, firefox for your other internet usage.

It does seem this open source method of bug fixing suffers from the classic bug fixing issue: lack of ownership.

    
    

    
  
I have my brother use Safari...all is well. I too find this pretty sad.

    
    

    
  
I've had the same problem with Windows XP pro and hotmail.  I removed version 3.6 and reinstalled it, and rebooted PC.  No luck.  

I am now using version 3.5.8 and will either have to stick with it or swtich to an alternative like Chrome, because email is a vital browser function for me.

Greg N

    
    

    
  
Folks, we have enough comments about this being reproducible and present across all platforms of 3.6.   We dont need anymore "i see it too" or "use safari or IE" comments.  What we do need is investigation against the Firefox 3.6 nightlies to determine a regression range on which build it broke at.

If you'd like to help, please download builds at ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/, and try to track down the nightly trunk build that it first broke.  I started going through the builds, and still see this issue reproduce on the 11-28-2010 build.  still need to keep backtracking.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091128 Minefield/3.7a1pre

    
    

    
  
(In reply to comment #60)
> I started going through the
> builds, and still see this issue reproduce on the 11-28-2010 build.  still need
> to keep backtracking.

Correction, 11-28-2009 build.

    
    

    
  
I thought it would be fixed in 3.6.2.
Forward works correct on XP Pro but on Vista the problem still exists.

    
    

    
  
I've been unable to reproduce it for two days now. Even on old builds where it did definitely break before. Because of this I have upgraded to 3.6.2 and it all appears to work. I used to get it failing 90% of the time.

Anyone else noticing this or am I just getting lucky?

    
    

    
  
Roc, Ehsan, Peter, Jeff: can you please take a look at comment 50 and see if you can track down what's happening here? Seems to be related to "rich text messages". Consider this a high priority, it's one of our top user support request items. Tony Chung can help you (tchung in irc) reproduce.

    
    

    
  
here's a nice little screencast i made of it reproducing on Fx3.6.   It's more for your visual information, as there are enough common comments describing the problem.

http://screencast.com/t/MjA1MDdjZTA

    
    

    
  
Tony love the screencast - looks like a great product and also a great reproduction of issue.

Just a  personal note re comment 60. I take offense at that comment. Either Firefox has a forum for just users or a forum for just fixers; when you have a forum for both then you have to expect some user frustration and some work around suggestions. I put my issue on here because I'm a user, I just want a fix or I leave the product.

Not that I don't appreciate your work and your continued efforts to find a fix, just saying that there are multiple stakeholders here.

And those stakeholders might just be the best advoates Firefox has. We work in offices and with people who don't even know what an internet browser is, they just think you get on the internet through IE, period.When we tell them firefox is great we mean it, we just need to be sure that it works with the worlds biggest email client, or else we and firefox more importantly look like fools.

Bon chance from Switzerland.

    
    

    
  
Regarding the capture movie of the bug.

I don't like to take up people's time, I'm just a guy who despises MS and uses Mozilla.  I'm not competent to fix.

When I was using 3.6 (I have un-installed and moved back to 3.5.8) it was EXACTLY the same as in the posted capture EXCEPT that the bug ALSO appeared in the FORWARD mode.  FORWARD mode works fine in the posted capture.

I know because I tried to use "Forward" as a "workaround" to the fact that text was disappearing in reply.  Figured I would just copy in the sender to whom replying.  

But that work around didn't work, because the same bug was operating.

Hope that helps,

Greg N

    
    

    
  
(In reply to comment #66)

> Just a  personal note re comment 60. I take offense at that comment. Either
> Firefox has a forum for just users or a forum for just fixers; when you have a
> forum for both then you have to expect some user frustration and some work
> around suggestions. I put my issue on here because I'm a user, I just want a
> fix or I leave the product.

I don't mean to offend but bugzilla is not a forum no matter how it may appear to be one. It is a tool to help track and fix bugs. Comment 60 was not offensive in anyway. Bugs get harder to understand the more comments they have. Having 10, or 20, or 100 "me too" comments only makes it harder to figure out what is going on in the bug. All Tony was trying to do was let people know we have enough information and that the "me too" comments were beginning to detract from the usefulness of the bug.

    
    

    
  
Cool  - I'll bug out then and try FF in a couple of months and see if it's fixed.

Incidentally - what's the correct place to raise an issue so that people on bugzilla can fix it?! Because bugzilla seemed to be the only place.

    
    

    
  
Thanks bob.  Tomeeles, please dont take offense, i was merely citing point #1 in
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html, containing a link to
an appropriate newsgroup for discussion.  As mentioned, we're all trying to
solve the same problem here; but cutting out some of the noise is necessary for
investigation.  

This is the last comment i'll make about etiquette discussion here.

(In reply to comment #69)
> Incidentally - what's the correct place to raise an issue so that people on
> bugzilla can fix it?! Because bugzilla seemed to be the only place.

try mozilla.dev.apps.firefox, mozilla.dev.platform, or mozilla.support?

    
    

    
  
(In reply to comment #64)
> Roc, Ehsan, Peter, Jeff: can you please take a look at comment 50 and see if
> you can track down what's happening here? Seems to be related to "rich text
> messages". Consider this a high priority, it's one of our top user support
> request items. Tony Chung can help you (tchung in irc) reproduce.

Richt text? Really? That remembers me of bug 542642 where we had a similar problem with Gmail. That problem is fixed in 3.6.2. So could both bugs be related?

    
    

    
  
Henrik, per comment 47 and comment 50 (which are hard to find in all the noise, I know), this bug is NOT the same as bug 542642.  Comment 46 was all about trying to figure out whether it was.

    
    

    
  
So, I may have some clue as to what's happening here.  Using Jeff's proxy (http://muizelaar.blogspot.com/2010/01/reproducing-bugs-on-complicated.html), I've recorded two sessions where I opened www.hotmail.com, signed in, went to Inbox, opened a mail containing a picture, and hit Forward.

I generated a diff of these two runs, and I'm reading through it.  There's this line in the diff which caught my attention:

-<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta http-equiv="x-dns-prefetch-control" value="off" /><script>Browser={isFF:true,isFF2:false,isFF3:true};</script>^M
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta http-equiv="x-dns-prefetch-control" value="off" /><meta name="DownloadOptions" content="noopen" /><script>Browser={isFF:true,isFF2:true,isFF3:false};</scr     ipt>^M

The "-" line is what is being sent to 3.5 UAs, and "+" is what is being sent to 3.7 UAs.  It seems that Hotmail is thinking that 3.6 and trunk are Firefox 2, which doesn't seem to be great.

The code is included in the page sent at this URI: http://sn132w.snt132.mail.live.com/default.aspx?wa=wsignin1.0

This looks like a problem on their side.  I'm investigating the logs further.

    
    

    
  


  
Here's the diff of the two logs, for the curious.

Reading this takes some effort, because you have to ignore all the junk that is there because of things like time differences, cookie hash difference, etc.

    
    

    
  
So, as a followup to comment 73, I didn't saw any other significant differences.

I looked at the javascript that they send the browser, and there are a few things different if Browser.isFF2==true.

    
    

    
  
Something i've been trying, was to fake the UA agent for a broken trunk build into Firefox 3.5.8, and retrying the tests.   Result: could not reproduce the issue.

I then tried the opposite, faking the UA agent for Fx3.5.8 into the broken trunk build, and retrying the tests.  Result: still reproduces the blank body.

So my experiment proved it wasnt user agent incompatibility related.

    
    

    
  
Comment #73 makes it very clear that they are detecting FF3.6/3.7 as FF2. Maybe they're not sniffing the user-agent but using some other browser-sniffing approach.

    
    

    
  
Cww, can you get the Hotmail team on the line again and tell them they're detecting us as FF2?

Ehsan, can you dig through the scripts sent to the browser and figure out why isFF2 is being set?

    
    

    
  
Already on it.  Thanks, ehsan!

    
    

    
  
Documenting some of our IRC conversations here.

(In reply to comment #77)
> Comment #73 makes it very clear that they are detecting FF3.6/3.7 as FF2. Maybe
> they're not sniffing the user-agent but using some other browser-sniffing
> approach.

The UA sniffing is done on the server, because the code which is sent to the client has |isFF2:true| set, and that's it.

They also set some class attributes to Firefox related names with Firefox 3.5 UA, but that may only be related to styling (I verified that they're not using querySelector in their js code.)

In addition to that, they seem to be sending some extra HTML for trunk UA (like cut/copy/paste buttons) and not to Firefox 3.5 UA, but that doesn't seem relevant to this problem as well.

    
    

    
  
(In reply to comment #80)
> The UA sniffing is done on the server, because the code which is sent to the
> client has |isFF2:true| set, and that's it.

Oh, also, they seem to have lots of code like:

ua.indexOf("firefox")

which is wrong and will fail to detect trunk builds (they should be looking for "gecko"), but that doesn't explain why things break for Firefox 3.6 builds.

    
    

    
  
Confirmed during the repro with the proxy on, that isFF2:true, and isFF3:false. 

host-3-199:log tchung$ grep isFF2 *
http%3A%2F%2Fco112w.col112.mail.live.com%2Fmail%2FEditMessageLight.aspx%3FReadMessageId%3D26d30699-3356-11df-93a8-00215ad9a7a6%26FolderID%3D00000000-0000-0000-0000-000000000001%26CP%3D-1%26n%3D1943185204%26Action%3DForward%26AllowUnsafe%3DFalse:<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta http-equiv="x-dns-prefetch-control" value="off" /><script>Browser={isFF:true,isFF2:true,isFF3:false};</script>

    
    

    
  
just to resolve the UA client test scenario... i ran Fx3.6 masking it under a Fx3.5.8 agent, and it still reproduces the issue there.   So we'll need to keep hunting a regression-range down.

    
    

    
  
(In reply to comment #83)
> just to resolve the UA client test scenario... i ran Fx3.6 masking it under a
> Fx3.5.8 agent, and it still reproduces the issue there.   So we'll need to keep
> hunting a regression-range down.

When you run Fx3.6 with the Fx3.5.8 user agent, do you get isFF2:true or false?

    
    

    
  
isFF2:true.

Tony-Chungs-MacBook-Pro:log tchung$ grep FF2 *
http%3A%2F%2Fco112w.col112.mail.live.com%2Fmail%2FEditMessageLight.aspx%3FReadMessageId%3D26d30699-3356-11df-93a8-00215ad9a7a6%26FolderID%3D00000000-0000-0000-0000-000000000001%26CP%3D-1%26n%3D1892805631%26Action%3DForward%26AllowUnsafe%3DFalse:<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta http-equiv="x-dns-prefetch-control" value="off" /><script>Browser={isFF:true,isFF2:false,isFF3:true};</script>
http%3A%2F%2Fco112w.col112.mail.live.com%2Fmail%2FEditMessageLight.aspx%3FReadMessageId%3D26d30699-3356-11df-93a8-00215ad9a7a6%26FolderID%3D00000000-0000-0000-0000-000000000001%26CP%3D-1%26n%3D996482669%26Action%3DReplyAll%26AllowUnsafe%3DTrue:<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta http-equiv="x-dns-prefetch-control" value="off" /><script>Browser={isFF:true,isFF2:false,isFF3:true};</script>
http%3A%2F%2Fco112w.col112.mail.live.com%2Fmail%2FEditMessageLight.aspx%3FReadMessageId%3D7a4ac8c7-3312-11df-bbd6-00237de3f582%26FolderID%3D00000000-0000-0000-0000-000000000001%26CP%3D-1%26n%3D1090878510%26Action%3DReply%26AllowUnsafe%3DFalse:<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta http-equiv="x-dns-prefetch-control" value="off" /><script>Browser={isFF:true,isFF2:false,isFF3:true};</script>
http%3A%2F%2Fco112w.col112.mail.live.com%2Fmail%2FEditMessageLight.aspx%3FReadMessageId%3D7f1f0e25-379d-11df-8a56-00237de41806%26FolderID%3D00000000-0000-0000-0000-000000000001%26CP%3D-1%26n%3D593327779%26Action%3DForward%26AllowUnsafe%3DFalse:<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta http-equiv="x-dns-prefetch-control" value="off" /><script>Browser={isFF:true,isFF2:false,isFF3:true};</script>
http%3A%2F%2Fco112w.col112.mail.live.com%2Fmail%2FEditMessageLight.aspx%3FReadMessageId%3Db30ed446-379d-11df-8790-00215ad73b02%26FolderID%3D00000000-0000-0000-0000-000000000001%26CP%3D-1%26n%3D268254503%26Action%3DForward%26AllowUnsafe%3DFalse:<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta http-equiv="x-dns-prefetch-control" value="off" /><script>Browser={isFF:true,isFF2:false,isFF3:true};</script>
http%3A%2F%2Fco112w.col112.mail.live.com%2Fmail%2FInboxLight.aspx%3Fn%3D1422341104:<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta http-equiv="x-dns-prefetch-control" value="off" /><script>Browser={isFF:true,isFF2:false,isFF3:true};</script>
http%3A%2F%2Fco112w.col112.mail.live.com%2Fmail%2FInboxLight.aspx%3Fn%3D3416208:<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta http-equiv="x-dns-prefetch-control" value="off" /><script>Browser={isFF:true,isFF2:false,isFF3:true};</script>
http%3A%2F%2Fco112w.col112.mail.live.com%2Fmail%2FInboxLight.aspx%3Fn%3D411683973:<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta http-equiv="x-dns-prefetch-control" value="off" /><script>Browser={isFF:true,isFF2:false,isFF3:true};</script>
http%3A%2F%2Fco112w.col112.mail.live.com%2Fmail%2FInboxLight.aspx%3Fn%3D813689040:<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta http-equiv="x-dns-prefetch-control" value="off" /><script>Browser={isFF:true,isFF2:false,isFF3:true};</script>

    
    

    
  
I'm running 3.6.2 in the original environment I reported this bug against, and I'm getting isFF3:true.  I'm seeing the same setting running 3.6.2 under Windows XP on a different machine.  But the Mac OS X machine is still exhibiting the problem consistently, while the Windows XP machine is working fine.  In both cases I'm using the same Hotmail account.

Attaching screen shot showing the isFF3:true setting with empty response form and user agent identification.

    
    

    
  
(In reply to comment #85)
> isFF2:true.

Oops typo.  i mean isFF2:false!  isFF3:true.

    
    

    
  
I get this range. Its really finicky. Would appreciate it if someone else validated the range.

*Possible* regression range:

works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090605 Minefield/3.6a1pre

broken:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090606 Minefield/3.6a1pre

    
    

    
  
(In reply to comment #90)
> I get this range. Its really finicky. Would appreciate it if someone else
> validated the range.
> 
> *Possible* regression range:
> 
> works:
> Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090605
> Minefield/3.6a1pre
> 
> broken:
> Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090606
> Minefield/3.6a1pre

Matt, can you please open about:buildconfig on each of those two builds, and report the revision logs here (right next to "Built from" on that page)?  Thanks!

    
    

    
  
I didn't add them because I don't fully trust my range and wanted further verification. Here they are.

(In reply to comment #90)
> works:
> Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090605
> Minefield/3.6a1pre
http://hg.mozilla.org/mozilla-central/rev/ae2437e9e9dd

> broken:
> Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090606
> Minefield/3.6a1pre
http://hg.mozilla.org/mozilla-central/rev/fb64ba1cb3ad

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ae2437e9e9dd&tochange=fb64ba1cb3ad

    
    

    
  
(In reply to comment #94)
> Apparently the range in comment 93 is wrong, but tching came up with a range:
> 
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c4fcaec2898a&tochange=e762b03da104

This was my first pass at a rangefinder, but yes, it was range between 20090508-20090510 builds i was seeing--

Works: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2a1pre) Gecko/20090508 Minefield/3.6a1pre

Broke: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2a1pre) Gecko/20090510 Minefield/3.6a1pre

    
    

    
  
(In reply to comment #95)
> (In reply to comment #94)
> > Apparently the range in comment 93 is wrong, but tching came up with a range:
> > 
> > http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c4fcaec2898a&tochange=e762b03da104
> 
> This was my first pass at a rangefinder, but yes, it was range between
> 20090508-20090510 builds i was seeing--
> 
> Works: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2a1pre)
> Gecko/20090508 Minefield/3.6a1pre
> 
> Broke: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2a1pre)
> Gecko/20090510 Minefield/3.6a1pre

ignore this range.  i am still seeing this reproduce on an older build dating: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2a1pre) Gecko/20090501 Minefield/3.6a1pre.   

back to the hunt.

    
    

    
  
Try 2 for me.

broken:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090401 Minefield/3.6a1pre

    
    

    
  
broken:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090318 Minefield/3.6a1pre

    
    

    
  
Build worked : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090316 Minefield/3.2a1pre
Build broken : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) 
Gecko/20090317 Minefield/3.6a1pre

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2fbc3d17e654&tochange=01987cfc569b

    
    

    
  
(In reply to comment #102)
> Build worked : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre)
> Gecko/20090316 Minefield/3.2a1pre
> Build broken : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) 
> Gecko/20090317 Minefield/3.6a1pre
> 
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2fbc3d17e654&tochange=01987cfc569b

Tony, can you confirm this range.  If yes, we can start bisecting this one.

    
    

    
  
I am perplexed that I have a version of 3.6 (*not* 3.6.2) on my office computer (which I use infrequently) that does NOT have this issue.  My home desktop *does* have the issue (forcing me to install 3.5.8).   

If there is any useful information that can be gleaned from the computer on which the bug appears versus the work computer on which it does not appear please let me know.  I am not a programmer and would need to be coached off-list.  

thanks

Greg N

    
    

    
  
In the original environment I reported this bug against, this range works fine for me, I can't duplicate the bug.  I tried:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2a1pre) Gecko/20090315 Minefield/3.2a1pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2a1pre) Gecko/20090317 Minefield/3.2a1pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2a1pre) Gecko/20090317 Minefield/3.6a1pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2a1pre) Gecko/20090318 Minefield/3.6a1pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2a1pre) Gecko/20090319 Minefield/3.6a1pre

(I confirmed that it's still occurring in the same environment with 3.6.2 before and after these tests.)

    
    

    
  
(In reply to comment #105)
> In the original environment I reported this bug against, this range works fine
> for me, I can't duplicate the bug.  I tried:

I can't speak for the others, but I think it took me 20 minutes to get 20090318 to break just once. So, if you only tested the builds for a short time, the bug might not have shown up...

    
    

    
  
(In reply to comment #102)
> Build worked : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre)
> Gecko/20090316 Minefield/3.2a1pre
> Build broken : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) 
> Gecko/20090317 Minefield/3.6a1pre
> 
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2fbc3d17e654&tochange=01987cfc569b

Tested with same regression range on MAC OSX 10.5.2 platform,Here are my findings:
Build worked :  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090316 Minefield/3.2a1pre

Build broken : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090317 Minefield/3.6a1pre

    
    

    
  
(In reply to comment #108)
> (In reply to comment #102)
> > Build worked : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre)
> > Gecko/20090316 Minefield/3.2a1pre
> > Build broken : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) 
> > Gecko/20090317 Minefield/3.6a1pre
> > 
> > http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2fbc3d17e654&tochange=01987cfc569b
> 
> Tested with same regression range on MAC OSX 10.5.2 platform,Here are my
> findings:
> Build worked :  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
> rv:1.9.2a1pre) Gecko/20090316 Minefield/3.2a1pre
> 
> Build broken : Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
> rv:1.9.2a1pre) Gecko/20090317 Minefield/3.6a1pre

Aravind, can you check if this repros also happens on windows with your range?

    
    

    
  
Tony, I am able to reproduce with the above range in win xp, win 7 and Mac OSX.

    
    

    
  
Bisecting the range in comment 102 gives us this range.

http://hg.mozilla.org/mozilla-central/rev/01987cfc569b

I'm going to produce a trunk build without that patch to see if it's the real culprit.

    
    

    
  
With the help of tchung and Tomcat, we finally determined this to be a regression from the fix to bug 468594.

CCing Bjarne who wrote the patch to that bug, and biesi who reviewed it.
Assignee: tchung → nobody
Blocks: 468594
Component: General → Networking: Cache
Keywords: regressionwindow-wanted → regression
Product: Firefox → Core
QA Contact: general → networking.cache
Version: 3.6 Branch → 1.9.2 Branch

    
  
Keywords: qawanted

    
    

    
  
Woohoo!  double thanks to tomcat and ehsan for getting on this.  It's been quite a journey; so lets hope its the right fix.
blocking1.9.2: --- → ?
blocking2.0: --- → ?

          status1.9.2:
          --- → ?

    
    

    
  
Sounds like a great thing to fix, but probably not "blocking" because we've shipped two 3.6 releases (and all the betas) with this bug.

A patch, reviews, and a trunk fix would be great to have before trying to get this into the stable branch.
blocking1.9.2: ? → ---

          status1.9.2:
          ? → wanted

    
    

    
  
(In reply to comment #112)
> With the help of tchung and Tomcat, we finally determined this to be a
> regression from the fix to bug 468594.
> 
> CCing Bjarne who wrote the patch to that bug, and biesi who reviewed it.

Please observe that bug #490095 has a patch which improves the patch for bug #468594 (fixing a rather obvious, early regression) ; have you tried to reproduce with that patch applied?

The issue which has been puzzling me while reading the, ehh, lengthy discussion above :)  is that there seem to be a clear understanding that this problem occurs for POST-requests (comment #47 in particular)? The fix in the identified bug only applies to http GET-requests.

However, I've been trying to reproduce this on my trunk-build with the following results :

1) reply to text-only msg : text in email is inlined
2) fwd text-only msg : text in email is inlined
3) reply to msg w/ attached img : text in email is inlined, no img is indicated to be attached
4) fwd msg w/ img attached : text in email is inlined, AND img is indicated to be attached

All results reproducible (limited by my patience at 1 am in the morning though  :)  )

Since I'm no regular hotmail-user, could someone let me know if the above are expected results? (Or whether I'm doing something wrong ; how do I produce a "rich-text" msg with Thunderbird, for example? Html-mode?)

    
    

    
  
(In reply to comment #115)
> (In reply to comment #112)
>how do I produce a
> "rich-text" msg with Thunderbird, for example? Html-mode?)

Hey Bjarne, i will sent you the login details to the testaccount i used for reproducting this issue - it has some rich-text emails in there :)

    
    

    
  
(In reply to comment #115)
> Please observe that bug #490095 has a patch which improves the patch for bug
> #468594 (fixing a rather obvious, early regression) ; have you tried to
> reproduce with that patch applied?

Are you talking about the patch which landed as part of that bug?  If yes, then that doesn't address this problem, since this bug is present in trunk builds, which already have that patch.

> The issue which has been puzzling me while reading the, ehh, lengthy discussion
> above :)  is that there seem to be a clear understanding that this problem
> occurs for POST-requests (comment #47 in particular)? The fix in the identified
> bug only applies to http GET-requests.

I guess you mean comment 46.  Actually I think Boris was wrong there.  There is nothing in this bug which indicates that this is a problem with POST requests.  See below for a description of what I think is happening here.

Also, at this point, there is little possibility that this is not actually a regression from bug 468594, as all of the evidence in reproducing this problem points to that bug!  :-)

> However, I've been trying to reproduce this on my trunk-build with the
> following results :
> 
> 1) reply to text-only msg : text in email is inlined
> 2) fwd text-only msg : text in email is inlined
> 3) reply to msg w/ attached img : text in email is inlined, no img is indicated
> to be attached
> 4) fwd msg w/ img attached : text in email is inlined, AND img is indicated to
> be attached
> 
> All results reproducible (limited by my patience at 1 am in the morning though 
> :)  )
> 
> Since I'm no regular hotmail-user, could someone let me know if the above are
> expected results? (Or whether I'm doing something wrong ; how do I produce a
> "rich-text" msg with Thunderbird, for example? Html-mode?)

tchung came up with a clear set of steps to reproduce this problem in comment 50.  Please note that this is not 100% reproducible, but given enough number of tries, it will happen.  on my machine, it happens 1 out of 10-15 times, but apparently this happens more frequently on other systems (it appears that slightly slower systems tend to show this problem more often.)

Here is an analysis of what I believe is happening here.

The body of the message appears in an iframe like below.

<iframe src="RteFrame_15.1.3039.0211.html?pf=pf" onload="if(window.RTE &amp;&amp; RTE.turnOn){RTE.turnOn(this,true);}else{if(!window.__RTE)window.__RTE=[];window.__RTE.push([this,true]);}" frameready="yes" class="RichText" id="RichTextEditor_surface"></iframe>

This iframe is loaded via a GET request.  I think that sometimes this GET request fails to finish successfully, therefore the user will end up with a blank iframe, which appears as a big white area in place of the body of the replied to or forwarded email.

    
    

    
  
Comment 118 has the problem about right.

I am just your average Joe so if I can tell u exactly what is problem it may help.

Windows XP Pro, build latset with all Updates.

Normally when sending any message I automatically get appended a signature message.  This now does not work even with a "New" message and I have an empty frame.  I can type nessages etc and works ok, but no signature .

Neither Forward, Reply All or Reply will load content  BUT alo note, neither does the automatic signature box.  so there is no signature and no content and only an empty frame.  I can write messages and send and attach..all this functionality is there.

Waving curor over New, Reply All, Reply and Forward...the activity messages at the bottom left say when cursor is on any of the above "javascript:;"

selecting an email I get a void(0) falsh in one message and the readable message appears.
(very hard to read all these things because it happens quickly)
then after selecting N, RA, R and F I get a series of waiting and transferring messages and a Done and the Frame is empty. The content of the email and the automatic signature are not there, and they used to be in earlier FF versions

    
    

    
  
Blocking on this regression. Bjarne, I'm assigning this to you, but feel free to reassign if this turns out to not be something you can work on.
Assignee: nobody → bjarne
blocking2.0: ? → beta1+

    
    

    
  
FF 3.6.3  vista 32 bit

i used to have to go back to inbox (hotmail) and clear cache then
go to the email I wanted to respond to and click respond to have the 
reply include previous email text.

i just updated my java from xxx.18 to xxx.19

now I can click reply and if reply window is empty I don't have to
go back to inbox, I can clear cache and refresh window to get previous 
text back.   Works most of the time.

    
    

    
  
First, let me emphasize that I'm not trying to wriggle out of this - just want to make sure we're barking up the right tree. :)

The patch identified to cause this regression will cause necko to validate certain get-requests which used to be erroneously cached. I have a hard time imagining how this may cause something like what we see, but I'll try again to reproduce. Thanks to Tomcat for providing detailed info and credentials over email!

> Also, at this point, there is little possibility that this is not actually a
> regression from bug 468594, as all of the evidence in reproducing this problem
> points to that bug!  :-)

My point is that a build which includes the patch for bug #468594 should also include the patch for bug #490095, or be subject to the (known) regression described in bug #490095. It would be interesting to know if the build used in comment #112 with the patch for bug #490095 also reproduces the hotmail-problem.

> Here is an analysis of what I believe is happening here.

[ snip ]

Your analysis is a good starting-point for a test if I can reproduce this problem and identify the issue. :)
Status: NEW → ASSIGNED

    
    

    
  
(In reply to comment #122)
> i just updated my java from xxx.18 to xxx.19

Can anyone experiencing the hotmail-problem verify or falsify that this helps?

    
    

    
  
@Bjarne - I had Java 6.0.170 so have just upgraded to 6.0.190.
It made a difference in that instead of Forward HTML never working, it now works about 1/3 of the time.

    
    

    
  
@bjarne - I had Java .17 also and upgraded to .19.   No measurable difference.  Automatic signatures do not post into the message when using "New" email.  Reply, Reply All and Forward all do not put automatic signature or content of previous email in the frame.  Normal typing and attachments work in the frame once it is there, but it is not loaded up with the right things to start with.  I tried all the functions serveral times and none worked once.  How many times do you need to do it to decide its intermittent?  But for me as-is, FF with Hotmail doesn't work.

    
    

    
  
(In reply to comment #123)
> First, let me emphasize that I'm not trying to wriggle out of this - just want
> to make sure we're barking up the right tree. :)

Oh, sure, I wasn't implying that you're trying to do that!  ;-)  I was merely pointing out that there is little possibility that the bug is being caused by something else.  See below for why that is.

> The patch identified to cause this regression will cause necko to validate
> certain get-requests which used to be erroneously cached. I have a hard time
> imagining how this may cause something like what we see, but I'll try again to
> reproduce. Thanks to Tomcat for providing detailed info and credentials over
> email!

I also have a hard time understanding this.

> > Also, at this point, there is little possibility that this is not actually a
> > regression from bug 468594, as all of the evidence in reproducing this problem
> > points to that bug!  :-)
> 
> My point is that a build which includes the patch for bug #468594 should also
> include the patch for bug #490095, or be subject to the (known) regression
> described in bug #490095. It would be interesting to know if the build used in
> comment #112 with the patch for bug #490095 also reproduces the
> hotmail-problem.

So, let me elaborate what led us to comment 112.  We were bisecting a known regression range, and the bisect resulted in the patch from bug 468594.  Also, please note that the build resulting from the bisect did _not_ include the patch from bug 490095.  After finding that, I tried a trunk build which disabled the check added in bug 468594 (the patch landed as part of that bug couldn't be unapplied cleanly any more.)  That build, however, did have the patch to bug 490095 (as it was a build off trunk) and the problem went away.

So, to the best of my judgment, the patch from bug 468594 is somehow causing this.

(In reply to comment #124)
> (In reply to comment #122)
> > i just updated my java from xxx.18 to xxx.19
> 
> Can anyone experiencing the hotmail-problem verify or falsify that this helps?

FWIW, I don't have java installed on my system at all.  Tomcat and tchung can probably tell you what version of java they have, if any.

    
    

    
  
(In reply to comment #127)
> After finding that, I tried a trunk build which
> disabled the check added in bug 468594

[snip ] 

> and the problem went away.

This is useful info and pretty conclusive, I agree. If I understand you correctly, you disabled the check

" else if (MustValidateBasedOnQueryUrl()) "

in nsHttpChannel::CheckCache() and the problem went away? Very good! (Why didn't you say so right away?  :) ) Are you using optimized builds or have you reproduced on logging/debug-builds?

> FWIW, I don't have java installed on my system at all.  Tomcat and tchung can
> probably tell you what version of java they have, if any.

It doesn't sound like Java is relevant to this issue, but it was worth a shot. Thanks to you guys who reported back on this!

I'm still unable to reproduce this on my (Linux) system - working on setting up the build-environment on a Mac...

    
    

    
  
(In reply to comment #128)
> 
> It doesn't sound like Java is relevant to this issue, but it was worth a shot.
> Thanks to you guys who reported back on this!

correct, java was not a factor for me...

    
    

    
  
Hi Guys,    just a small add to my comment 126 - right click and using "reload frame" doesn't make any difference either. There is a lot of "waiting","reading" and "transfering" going on at the bottom left of hotmail, but when "Done" arrives the frame is blank.

Ss still no automatic signature in "New" email, or in "Reply", "Reply All" or "Forward" and no content i.e. the email being replied to.  Frame completely empty.  AFAIK these are all the symptoms as seen by a user.

    
    

    
  
Still cannot reproduce but here's the working-theory :

The patch identified to cause this regression can only result in extra validations with the server in certain situations (it can never cause fewer validations). From my logs I see these situations for the object in question, which results in (etagged) requests and 304 (not modified) responses from the server. Response 304 allows FF to read the object from its cache, however, code-path to read from cache after a 304 is not the same as code-path reading from cache if the cached content was considered fresh without asking the server. So, I'm currently analyzing the code-differences.

    
    

    
  
(In reply to comment #128)
> This is useful info and pretty conclusive, I agree. If I understand you
> correctly, you disabled the check
> 
> " else if (MustValidateBasedOnQueryUrl()) "
> 
> in nsHttpChannel::CheckCache() and the problem went away?

That's right.

> Very good! (Why
> didn't you say so right away?  :) )

Sorry, I was assuming that you can read my mind, which seems like a wrong assumption.  ;-)

> Are you using optimized builds or have you
> reproduced on logging/debug-builds?

I only tried optimized builds without debugging information.

(In reply to comment #131)
> The patch identified to cause this regression can only result in extra
> validations with the server in certain situations (it can never cause fewer
> validations). From my logs I see these situations for the object in question,
> which results in (etagged) requests and 304 (not modified) responses from the
> server. Response 304 allows FF to read the object from its cache, however,
> code-path to read from cache after a 304 is not the same as code-path reading
> from cache if the cached content was considered fresh without asking the
> server. So, I'm currently analyzing the code-differences.

Looks a sane approach to me.  Thanks for following up on this!

    
    

    
  
Ehsan, do you have time to check the cached content of the "RteFrame_15...." object referred in comment #118 *after* this problem occurs? I.e. when you see this problem, could you open a new tab, enter "about:cache", click "List Cache Entries" for the Disk-cache and search (ctrl-f) for "RteFrame" ? It would be really interesting to see what it contains... If you have time, please also do this before the error occurs, so that we can see if the cache-entry has changed...

> Sorry, I was assuming that you can read my mind, which seems like a wrong
> assumption.  ;-)

I did try very hard, but it didn't work...  :)

    
    

    
  
Hmm...  just came across bug #478584. It describes symptoms which sounds very familiar to what we see here, but it was reported before the identified culprit landed.

Would it be possible to identify the patch which caused bug #478584? Does the workaround for it (bug #478584, comment #5) resolve the issue we see here?

(Not wriggling, just trying to gather more info about the issue.  ;) )

    
    

    
  
You guys may already know this, but immediately after loading Hotmail I went to tools/erros and there were lots of messages about unknown declarations etc, but there was only 1 error which I copied and pasted below

Error: Permission denied for <http://view.atdmt.com> (document.domain has not been set) to call method Location.toString on <http://sn119w.snt119.mail.live.com> (document.domain=<http://live.com>).

    
    

    
  
Guys, After posting comment 135 I rechecked "all messages" in Tools/Error console and there are too many to paste one at a time.  So by now (recapping) I had a clear error box, then loaded hotmail, then from a hotmail message about mozilla I opened (went to) this bug site and there were a bunch of messages.  Here are a few odd ones:
bugzilla.mozilla.org : potentially vulnerable to CVE-2009-3555
Warning: Error in parsing value for 'filter'.  Declaration dropped.
Source File: https://bugzilla.mozilla.org/skins/standard/yui/autocomplete.css
Line: 7
Warning: Unknown property '-moz-opacity'.  Declaration dropped.
Source File: https://bugzilla.mozilla.org/skins/standard/yui/autocomplete.css
Line: 7
Warning: Expected declaration but found '*'.  Skipped to next declaration.
Source File: https://bugzilla.mozilla.org/skins/standard/yui/calendar.css
Line: 7
Warning: Error in parsing value for 'white-space'.  Declaration dropped.
Source File: https://bugzilla.mozilla.org/skins/standard/global.css
Line: 280
Warning: Error in parsing value for 'white-space'.  Declaration dropped.
Source File: https://bugzilla.mozilla.org/skins/standard/global.css
Line: 279
Warning: Error in parsing value for 'white-space'.  Declaration dropped.
Source File: https://bugzilla.mozilla.org/skins/standard/global.css
Line: 280
Error: Permission denied for <http://view.atdmt.com> (document.domain has not been set) to call method Location.toString on <http://sn119w.snt119.mail.live.com> (document.domain=<http://live.com>).
Warning: Error in parsing value for 'cursor'.  Declaration dropped.
Source File: http://gfx8.hotmail.com/mail/15.1.3057.0331/styles/base/hig.css
Line: 388
Warning: Unknown property 'behavior'.  Declaration dropped.
Source File: http://gfx8.hotmail.com/mail/15.1.3057.0331/styles/base/hig.css
Line: 385
Warning: Unknown property 'behavior'.  Declaration dropped.
Source File: http://gfx8.hotmail.com/mail/15.1.3057.0331/styles/base/hig.css
Line: 381

THERE ARE A WHOLE BUNCH OD UNKNOWN PROPERTIES IN LINES ABOUT 360-380
THEN A FEW LIKE THE FOLLOWING IN LINE 19 36 154

Warning: Error in parsing value for 'color'.  Declaration dropped.
Source File: http://gfx8.hotmail.com/mail/15.1.3057.0331/styles/base/WebIM.css
Line: 19

I don't know what to send you but hope it helps

    
    

    
  
(In reply to comment #133)
> Ehsan, do you have time to check the cached content of the "RteFrame_15...."
> object referred in comment #118 *after* this problem occurs? I.e. when you see
> this problem, could you open a new tab, enter "about:cache", click "List Cache
> Entries" for the Disk-cache and search (ctrl-f) for "RteFrame" ? It would be
> really interesting to see what it contains... If you have time, please also do
> this before the error occurs, so that we can see if the cache-entry has
> changed...

I certainly can, but I always have a lot of problems reproducing this.  Tried ~20 times right now, and couldn't reproduce.  Tony/Tomcat, can any of you help with this?

(In reply to comment #134)
> Hmm...  just came across bug #478584. It describes symptoms which sounds very
> familiar to what we see here, but it was reported before the identified culprit
> landed.

Yes, it indeed looks similar to this bug.

> Would it be possible to identify the patch which caused bug #478584? Does the
> workaround for it (bug #478584, comment #5) resolve the issue we see here?

I bet our QA friends can help with this.  Adding qawanted to this bug and regressionwindow-wanted to the other one.
Keywords: qawanted

    
    

    
  
One question to you guys who experience this issue : After you've pressed e.g. "reply" and the original message has not been quoted in your reply, can you still type in text and send it? I.e. can you type in and send a reply, and the only problem is that the message to which you reply is not quoted?

    
    

    
  
Yes Bjarne - I can still type in the box....there does not appear to be anything blocking it....also, fyi, if the original message is, say, 2 screens long, the reply/forward message starts at only one screen.....so it does not appear to be a blank frame of the same size.

My current work-around: Copy the contents of the email with Ctrl+C, click on Forward/Reply, Paste using Ctrl+V
Hubby's work-around: Ditch Firefox, use IE! :-)

Cheers
Chris

    
    

    
  
Thanks, Chris. Let's see if we can come up with a more permanent and satisfactory solution...  :)

If anyone has a chance to produce a http-log of this failure it would be very helpful. See http://developer.mozilla.org/en/HTTP_Logging for instructions (contact me directly on email for details if this doesn't make sense to you).

    
    

    
  
Re. comment 133, here are the cache entries for a successful and a failed instance.  (In summary, it seems they are identical.)

Success:

key:	http://co113w.col113.mail.live.com/mail/RteFrame_15.1.3039.0211.html?pf=pf

fetch count:
	

2


last fetched:
	

2010-04-08 09:30:16


last modified:
	

2010-04-08 09:29:00


expires:
	

2010-04-13 22:41:35


Data size:
	

557


file on disk:
	

none


Security:
	

This document does not have any security info associated with it.




Client:
	

HTTP


request-method:
	

GET


request-Accept-Encoding:
	

gzip,deflate


response-head:
	

HTTP/1.1 200 OK
Content-Length: 557
Content-Type: text/html
Content-Encoding: gzip
Last-Modified: Fri, 12 Feb 2010 01:23:02 GMT
Accept-Ranges: bytes
Etag: "05f48eb81abca1:7a69"
Vary: Accept-Encoding
Server: Microsoft-IIS/6.0
P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo"
xxn: 59
Date: Thu, 08 Apr 2010 13:29:00 GMT


charset:
	

ISO-8859-1




00000000:  1f  8b  08  00  00  00  00  00  02  00  84  54  dd  92  d2  4c  ...........T...L
00000010:  10  bd  ff  aa  be  77  68  63  6d  11  14  b2  a1  bc  b1  02  .....whcm.......
00000020:  a1  4a  59  2d  b7  8c  82  ca  5e  78  39  64  26  c9  58  c9  .JY-....^x9d&.X.
00000030:  4c  9c  e9  ec  82  59  de  dd  c9  0f  10  40  76  fb  26  3d  L....Y.....@v.&=
00000040:  7d  fa  9c  ee  4c  77  32  49  30  4b  a7  ff  ff  07  c6  26  }...Lw2I0K.....&
00000050:  09  23  b4  f5  eb  b3  c6  4d  ca  00  37  39  f3  2d  64  6b  .#.....M..79.-dk
00000060:  bc  0e  b5  b6  ea  84  83  7d  5a  7e  09  ca  84  f1  38  41  .......}Z~....8A
00000070:  6f  e4  ba  57  e3  b0  50  5a  2a  af  ca  1f  6f  e1  fd  fc  o..W..PZ*...o...
00000080:  e6  67  99  13  4a  b9  88  bd  37  f9  7a  bc  92  8a  32  e5  .g..J...7.z...2.
00000090:  b9  c6  cd  88  8a  b9  a8  5c  93  e8  2c  52  c2  c5  d2  b0  .......\..,R....
000000a0:  06  4e  ad  19  49  81  c3  88  64  3c  dd  78  bd  a0  08  39  .N..I...d<.x...9
000000b0:  25  30  93  42  cb  94  f5  e0  05  cf  72  a9  90  08  1c  43  %0.B......r....C
000000c0:  9d  a8  f9  1f  e6  c1  5b  f7  ca  48  2d  ca  9d  32  cb  ba  ......[..H-..2..
000000d0:  99  6d  1b  c7  e1  ba  c9  60  3e  fb  fc  ed  6e  be  fc  30  .m.....`>...n..0
000000e0:  b8  0b  06  f3  a0  e5  0f  51  e6  a7  c9  2d  b2  92  88  32  .......Q...-...2
000000f0:  f3  e0  df  15  f6  c4  73  a8  65  9e  f7  f0  aa  ac  6e  6c  ......s.e.....nl
00000100:  c8  05  65  02  3d  97  8b  63  f8  c7  e2  dd  57  47  ff  2e  ..e.=..c....WG..
00000110:  78  1c  a7  9b  b2  b9  c4  9d  16  35  0f  46  61  94  af  e1  x........5.Fa...
00000120:  65  e4  ba  db  ce  04  af  eb  11  1e  cd  34  54  3c  c7  ee  e..........4T<..
00000130:  50  7f  91  7b  d2  44  4f  67  1b  15  22  44  2e  05  dc  0a  P..{.DOg.."D....
00000140:  8e  76  ff  18  2c  77  c7  83  f1  c8  7e  30  2f  20  1f  9c  .v..,w....~0/ ..
00000150:  54  86  a4  62  3a  9a  11  15  26  4e  f5  5a  eb  79  64  5b  T..b:...&N.Z.yd[
00000160:  79  e4  e7  91  d5  87  a9  0f  6e  2b  78  26  7a  6e  f7  44  y.......n+x&zn.D
00000170:  41  22  35  0a  92  31  f0  e1  b4  c8  0e  1a  5f  66  47  5c  A"5..1......_fG\
00000180:  69  bc  91  f8  51  c9  ec  7b  b5  ac  e0  ef  15  9d  94  68  i...Q..{.......h
00000190:  bc  6d  3b  84  9e  d3  1b  74  20  26  62  4c  a0  ff  84  b4  .m;....t &bL....
000001a0:  46  a2  9e  91  3b  af  3e  84  d1  93  a2  54  66  e6  73  e8  F...;.>....Tf.s.
000001b0:  aa  ea  62  a5  51  d9  6d  b9  d7  15  df  41  19  c8  07  a6  ..b.Q.m....A....
000001c0:  66  44  33  fb  92  1a  8f  c0  b6  ad  94  df  33  27  94  99  fD3.........3'..
000001d0:  05  be  df  8a  f7  e1  f1  11  1a  c4  ac  1d  9e  a2  ed  74  ...............t
000001e0:  9e  9b  d0  c1  0c  31  2c  32  66  94  f6  cd  37  ce  85  c6  .....1,2f...7...
000001f0:  b6  26  fc  74  e8  68  93  9b  15  9d  9a  50  7d  ec  fc  ab  .&.t.h.....P}...
00000200:  26  2b  49  37  20  45  2a  09  f5  ad  66  57  c7  16  24  9c  &+I7 E*...fW..$.
00000210:  b2  c8  b4  a4  cd  9e  ab  82  59  7b  6a  95  6e  0e  93  eb  ........Y{j.n...
00000220:  f6  df  f7  77  00  4a  3d  58  e5  04  05  00  00              ...w.J=X.....


Failure:

key:	http://co113w.col113.mail.live.com/mail/RteFrame_15.1.3039.0211.html?pf=pf

fetch count:
	

4


last fetched:
	

2010-04-08 09:31:42


last modified:
	

2010-04-08 09:30:50


expires:
	

2010-04-13 22:43:34


Data size:
	

557


file on disk:
	

none


Security:
	

This document does not have any security info associated with it.




Client:
	

HTTP


request-method:
	

GET


request-Accept-Encoding:
	

gzip,deflate


response-head:
	

HTTP/1.1 200 OK
Content-Length: 557
Content-Type: text/html
Content-Encoding: gzip
Last-Modified: Fri, 12 Feb 2010 01:23:02 GMT
Accept-Ranges: bytes
Etag: "05f48eb81abca1:7a69"
Vary: Accept-Encoding
Server: Microsoft-IIS/6.0
P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo"
xxn: 10
Date: Thu, 08 Apr 2010 13:30:49 GMT


charset:
	

ISO-8859-1




00000000:  1f  8b  08  00  00  00  00  00  02  00  84  54  dd  92  d2  4c  ...........T...L
00000010:  10  bd  ff  aa  be  77  68  63  6d  11  14  b2  a1  bc  b1  02  .....whcm.......
00000020:  a1  4a  59  2d  b7  8c  82  ca  5e  78  39  64  26  c9  58  c9  .JY-....^x9d&.X.
00000030:  4c  9c  e9  ec  82  59  de  dd  c9  0f  10  40  76  fb  26  3d  L....Y.....@v.&=
00000040:  7d  fa  9c  ee  4c  77  32  49  30  4b  a7  ff  ff  07  c6  26  }...Lw2I0K.....&
00000050:  09  23  b4  f5  eb  b3  c6  4d  ca  00  37  39  f3  2d  64  6b  .#.....M..79.-dk
00000060:  bc  0e  b5  b6  ea  84  83  7d  5a  7e  09  ca  84  f1  38  41  .......}Z~....8A
00000070:  6f  e4  ba  57  e3  b0  50  5a  2a  af  ca  1f  6f  e1  fd  fc  o..W..PZ*...o...
00000080:  e6  67  99  13  4a  b9  88  bd  37  f9  7a  bc  92  8a  32  e5  .g..J...7.z...2.
00000090:  b9  c6  cd  88  8a  b9  a8  5c  93  e8  2c  52  c2  c5  d2  b0  .......\..,R....
000000a0:  06  4e  ad  19  49  81  c3  88  64  3c  dd  78  bd  a0  08  39  .N..I...d<.x...9
000000b0:  25  30  93  42  cb  94  f5  e0  05  cf  72  a9  90  08  1c  43  %0.B......r....C
000000c0:  9d  a8  f9  1f  e6  c1  5b  f7  ca  48  2d  ca  9d  32  cb  ba  ......[..H-..2..
000000d0:  99  6d  1b  c7  e1  ba  c9  60  3e  fb  fc  ed  6e  be  fc  30  .m.....`>...n..0
000000e0:  b8  0b  06  f3  a0  e5  0f  51  e6  a7  c9  2d  b2  92  88  32  .......Q...-...2
000000f0:  f3  e0  df  15  f6  c4  73  a8  65  9e  f7  f0  aa  ac  6e  6c  ......s.e.....nl
00000100:  c8  05  65  02  3d  97  8b  63  f8  c7  e2  dd  57  47  ff  2e  ..e.=..c....WG..
00000110:  78  1c  a7  9b  b2  b9  c4  9d  16  35  0f  46  61  94  af  e1  x........5.Fa...
00000120:  65  e4  ba  db  ce  04  af  eb  11  1e  cd  34  54  3c  c7  ee  e..........4T<..
00000130:  50  7f  91  7b  d2  44  4f  67  1b  15  22  44  2e  05  dc  0a  P..{.DOg.."D....
00000140:  8e  76  ff  18  2c  77  c7  83  f1  c8  7e  30  2f  20  1f  9c  .v..,w....~0/ ..
00000150:  54  86  a4  62  3a  9a  11  15  26  4e  f5  5a  eb  79  64  5b  T..b:...&N.Z.yd[
00000160:  79  e4  e7  91  d5  87  a9  0f  6e  2b  78  26  7a  6e  f7  44  y.......n+x&zn.D
00000170:  41  22  35  0a  92  31  f0  e1  b4  c8  0e  1a  5f  66  47  5c  A"5..1......_fG\
00000180:  69  bc  91  f8  51  c9  ec  7b  b5  ac  e0  ef  15  9d  94  68  i...Q..{.......h
00000190:  bc  6d  3b  84  9e  d3  1b  74  20  26  62  4c  a0  ff  84  b4  .m;....t &bL....
000001a0:  46  a2  9e  91  3b  af  3e  84  d1  93  a2  54  66  e6  73  e8  F...;.>....Tf.s.
000001b0:  aa  ea  62  a5  51  d9  6d  b9  d7  15  df  41  19  c8  07  a6  ..b.Q.m....A....
000001c0:  66  44  33  fb  92  1a  8f  c0  b6  ad  94  df  33  27  94  99  fD3.........3'..
000001d0:  05  be  df  8a  f7  e1  f1  11  1a  c4  ac  1d  9e  a2  ed  74  ...............t
000001e0:  9e  9b  d0  c1  0c  31  2c  32  66  94  f6  cd  37  ce  85  c6  .....1,2f...7...
000001f0:  b6  26  fc  74  e8  68  93  9b  15  9d  9a  50  7d  ec  fc  ab  .&.t.h.....P}...
00000200:  26  2b  49  37  20  45  2a  09  f5  ad  66  57  c7  16  24  9c  &+I7 E*...fW..$.
00000210:  b2  c8  b4  a4  cd  9e  ab  82  59  7b  6a  95  6e  0e  93  eb  ........Y{j.n...
00000220:  f6  df  f7  77  00  4a  3d  58  e5  04  05  00  00              ...w.J=X.....

    
    

    
  
(In reply to comment #140)
> If anyone has a chance to produce a http-log of this failure it would be very
> helpful. See http://developer.mozilla.org/en/HTTP_Logging for instructions
> (contact me directly on email for details if this doesn't make sense to you).

Never mind this one...  I managed to reproduce the issue (eventually) with an optimized build and have the logs I need.

    
    

    
  
I'm starting to believe this is an issue with onload-events for iframes...

Observe that, even when the problem we discuss here has occurred, you can right-click in FF and choose "Select All", then right-click again and choose "View Selection Source" (note: this is not the same as "View->Page Source"). You will find a div and a textarea-element with styles { display:none } and there's an onload-handler for an iframe which seems to manipulate styles. AFAICS, the textarea-element contains the proper content, but is invisible due to its style, and I suspect that the onload-handler should have switched the style to {display: block } or something. Could anyone verify or falsify my observation? (For example that the missing signature is present, but invisible.)

Now, it still doesn't fully explain why the identified culprit/patch causes such behavior. But as stated earlier, the code-path (and thus the internal signaling-pattern) for handling a 304 followed by reading cached content is different from just reading cached content without verifying it at the server. This is still current theory, in other words, but focus is now on differences in internal signals and not on the cache itself.

    
    

    
  
By adding some instrumentation to nsDocumentViewer::LoadComplete you should be able to tell if the load event for the IFRAME is firing.

Should we back out the offending patch to restore Hotmail functionality while we continue to figure out the problem?

    
    

    
  
In the working case, this pattern is seen for the RteFrame_15...  resource (grepping for DOCSHELL):

1052301296[7fe233c12040]: DOCSHELL 7fe21ccbb000 created
1052301296[7fe233c12040]: DOCSHELL 7fe21ccbb000 InternalLoad http://bl143w.blu143.mail.live.com/mail/RteFrame_15.1.3039.0211.html?pf=pf
1052301296[7fe233c12040]: DOCSHELL 7fe21ccbb000 SetCurrentURI http://bl143w.blu143.mail.live.com/mail/RteFrame_15.1.3039.0211.html?pf=pf

and then DOCSHELL is destroyed later on. When the problem occurs, this pattern is seen

1052301296[7fe233c12040]: DOCSHELL 7fe21ea7e400 created
1052301296[7fe233c12040]: DOCSHELL 7fe21ea7e400 InternalLoad http://bl143w.blu143.mail.live.com/mail/RteFrame_15.1.3039.0211.html?pf=pf
1052301296[7fe233c12040]: DOCSHELL 7fe21ea7e400 SetCurrentURI about:blank
1052301296[7fe233c12040]: DOCSHELL 7fe21ea7e400 SetCurrentURI http://bl143w.blu143.mail.live.com/mail/RteFrame_15.1.3039.0211.html?pf=pf

Note that currentURI for the DOCSHELL is set to "about:blank" prior to setting the right url.

This is an observation. I'm not sure what it means, nor exactly why it occurs, but it's always the case. If anyone could offer an explanation for why DOCSHELL behaves like this, it would be very helpful...

    
    

    
  
(In reply to comment #145)
> Note that currentURI for the DOCSHELL is set to "about:blank" prior to setting
> the right url.

Forgot to mention : In this case, there is no log-entry about releasing the DOCSHELL.

    
    

    
  
(In reply to comment #146)
> (In reply to comment #145)
> > Note that currentURI for the DOCSHELL is set to "about:blank" prior to setting
> > the right url.
> 
> Forgot to mention : In this case, there is no log-entry about releasing the
> DOCSHELL.

Hmm...  the last one may have been a coincidence... not able to reproduce it.

    
    

    
  
If you have a docshell (essentially, some kind of frame that contains pages), and a document hasn't been loaded into it yet, and you try to look at its current document, you get a kind of fake blank document which is later replaced by the real document. I don't know the details of exactly how and why this happens.

    
    

    
  
Thanks for your input, roc! I added some logging to nsDocumentViewer and after some more digging and a few emails with ehsan and the hotmail-team I eventually see what the issue is :

The Rich Text Editor (RTE) is loaded into an iframe. Its onload-handler copies content from a texarea named "fMessageBody" which is a DOM-sibling of the RTE-iframe, and innerHTML-s this content into the body of the RTE. In the cases which fail, the textarea is empty when the onload-handler fires, and the body of the RTE ends up empty as well.

(I'll attach a raw log as well as an annotated extract.)

Why does bug #468594 make a difference? Well, it changes timing and the sequence of events because the RTE is not immediately loaded from cache, but must rather wait for the server to respond with a 304. This allows other threads/events to run while waiting, creating a time-window where things can happen, and (apparently) sometimes this includes clearing the content of the textarea.

Why not fix it by backing out patch for #468594? It may hide these particular problems with hotmail, but it wouldn't fix the real issue. See also comment #134. Moreover, when we move cache-reads to a separate thread (bug #513008), this issue may pop up with full strength again (and not only for hotmail). (I realize that the decision of backing out any particular patch is not mine though. :)  )

How to fix the particular issue we see here? IMO, the RTE should make sure it copies from the textarea only after the document to which the textarea belongs has loaded properly (i.e. some other onload-handler has fired). RTE seems to rely on a certain sequence of loading iframes within iframes (which may or may not be correct - I'm no expert on that).

Btw, could bug #557398 be related here? I'm not cc'd on it and thus cannot view it, but the title sounds relevant...

    
    

    
  
I'm still having the problem of no original message in my reply and no ability to forward Hotmail on Mac OS X with Firefox.  Works fine with other browsers.  When you find a solution can you put it into English (simple words of one syllable?) for those of us who don't speak computer?

    
    

    
  
Bjarne, is there anything we can do on our side to help mitigate this problem?  Also, could you please get in touch with our contacts form the Hotmail team and let them know of the problem and your proposed solution, so that they can start working on a fix on their side as well?

    
    

    
  
(In reply to comment #152)
> Bjarne, is there anything we can do on our side to help mitigate this problem? 

I need input from someone who deals with content and load-events on whether the assumption of the RTE is reasonable (assumption: content of textarea is available when onload fires), and if it is : what we can do about it.

> Also, could you please get in touch with our contacts form the Hotmail team and
> let them know of the problem and your proposed solution, so that they can start
> working on a fix on their side as well?

Yup.

(In reply to comment #149)
> Btw, could bug #557398 be related here? I'm not cc'd on it and thus cannot view
> it, but the title sounds relevant...

Applying the patch for bug #557398 does not fix this problem.

    
    

    
  
(In reply to comment #149)
> How to fix the particular issue we see here? IMO, the RTE should make sure it
> copies from the textarea only after the document to which the textarea belongs

You mean the document to which the RTE-iframe belongs?

> has loaded properly (i.e. some other onload-handler has fired). RTE seems to
> rely on a certain sequence of loading iframes within iframes (which may or may
> not be correct - I'm no expert on that).

You said the textarea is in the same document as the RTE-iframe element. Is it before or after the RTE-iframe element in the document?

Is the problem that the textarea never had any content because the document containing that textarea is only partially loaded? Or is the problem that the textarea had content but some script cleared it? You might want to log calls to nsHTMLInputElement::SetValue.

    
    

    
  
AFAICS, the document structure is something like this (I've removed some levels of divs between the iframes for clarity)

document
    iframe
        iframe (RTE) w/ onload-handler
        textarea

and, again AFAICS, the onload-handler assumes that the content of the textarea is available when it fires. In FF this assumption (apparently) sometimes holds and sometimes it doesn't, creating the problem we see.

(My apologies if I've misunderstood something fundamental here - this is how I understand it at the moment.)

First question is : Is the assumption reasonable?

    
    

    
  
> First question is : Is the assumption reasonable?

No, since it depends on the exact routing behavior of HTTP packets which is under neither our control nor that of the website (specifically, the packet with the "</textarea>" in it could come in later than everything related to the iframe).

    
    

    
  
    (In reply to comment #155)
    > and, again AFAICS, the onload-handler assumes that the content of the textarea
    > is available when it fires.
    That is a very bad assumption, and doesn't hold in general.
    (I doubt it holds always in any browser).
    If there is a network problem loading the rest of the document, and parsing
    has stopped just after <iframe>, its content is loaded but textarea isn't just
    there yet.

    Does the iframe load first about:blank and then some RTE document?
    There might be load event firing for the about:blank document.

    
    

    
  
So a theory:
if the networking patch causes RTE document load to take more time,
about:blank's load event fires and the load event listener added to
<iframe> is called. And the code doesn't expect that.

This would be clearly a bug in hotmail's js code.

    
    

    
  
IF YOU WANT TO SPEED UP THAT ISSUE RESOLVE - PLEASE VOTE !

    
    

    
  
In comment #29 we were in touch with someone from the Hotmail team ... we need to get in touch with them again and explain comments 155 to 158. Cww, can you do that?

    
    

    
  
I've been getting emails from the Hotmail team:  They know it's a problem on their end and they are working to fix it.  At this point, it's pretty much out of our hands.

    
  
Keywords: qawanted
Whiteboard: [qa-revisit-2010-05-30]

    
    

    
  
Hotmail-team confirms that the devised fix has been checked into their codebase and will be pushed out in the next major release. No ETA on that one, though, but they expect it to be "soon".

    
    

    
  
Hotmail just launched with a complete redesign.  Can someone who's consistently experiencing this problem please check that it doesn't occur in the new design?

    
    

    
  
I was the person who started this 165 comments ago.  I am also the least tech savy of all the people that have commented.  I found hitting the refresh icon does help but only sometimes.  Any changes that hotmail and/or firefox have made have not made its way to my Mac.

    
    

    
  
I have consistently experienced this problem.  It does not seem to be resolved, but it has improved.  Specifically, before the redesign replies would rarely include message content.  Now (and after clearing cache/cookies), replies inconsistently include message content, and more often than not (I'd say about 60% of the time).  The consistency seems to depend on the individual email -- some seem to usually include content, others seem to always lose it.

    
    

    
  
Thanks for your reply Tony... 

Hey all, same probs - clear the cache and it'll work once then you got nuthin until you clear it again.. 

tried to reply to Mr Chung, one of the bug-catchers (correct terminology?) 
i hear if you roll back to Mozilla 3.5.*  it goes away.. 

haven't done this yet in case you want me to try something.. 

Cheers Fionn>

    
    

    
  
should read:

tried to reply to Mr Chung, one of the bug-catchers (correct terminology?) 
and it happened straight away...

    
    

    
  
(In reply to comment #167)
> I have consistently experienced this problem.  It does not seem to be resolved,
> but it has improved.  Specifically, before the redesign replies would rarely
> include message content.  Now (and after clearing cache/cookies), replies
> inconsistently include message content, and more often than not (I'd say about
> 60% of the time).  The consistency seems to depend on the individual email --
> some seem to usually include content, others seem to always lose it.

Should add, I used Safari to compare for each email I tested, and it always included message content for every test.

    
    

    
  
After the redesign it seems to be working correctly on Windows 7 and Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

    
    

    
  
I am still having this problem with FF 3.6.3 and Win 7 Ultimate 64.  The first time I open a FF session an reply to a message the original message is posted in the reply, all subsequent reply's messages are blank.  I have to log-off an log-on again, then restart FF to get the first reply message to show in the reply.  All subsequent replies are blank.

    
    

    
  
(In reply to comment #174)
> I am still having this problem with FF 3.6.3 and Win 7 Ultimate 64.
> (snip)
> I have to log-off an log-on again, then restart FF to get the first reply message to show in the reply.
>  All subsequent replies are blank.

If problem similar to bug 542642, it should be fixed by Fx 3.6.2, and as written in comment #171, many of problems reported in this bug seems similar issue to bug 542642. And, if it's right, "log-off/log-on is done again or not" is irrelevant to problem.
Your case sounds cookie related Hot Mail's problem.
Clear Cache and all Hot mail related cookies. Your poblem still remains?
If still remains, Get HTTP log and check HTTP level flow.
> https://developer.mozilla.org/en/HTTP_Logging
> SET NSPR_LOG_MODULES=timestamp,nsHttp:5

    
    

    
  
@Wada:  It's not cookie related, but the log-off and log-on does work albeit only the for the first reply. All subsequent reply's do not quote the original email.    Shutting down FF and reopening has no effect.  

I have uploaded the last hundred lines or so of the HTTP log file here: http://www.4shared.com/document/IQSV6yek/HotmailNoPostHttpLog.html

Also what are the commands for disabling the logging.  Thanks

    
    

    
  
(In reply to comment #176)
> I have uploaded the last hundred lines or so of the HTTP log file here:

Have you tried to read the file content by yourself? Do you set timestamp,nsHttp:5 in environment variable? Please see what kind of log is written with each parameter by yourself, with simple case such as access to google.com only.
There is no way to stop logging while Fx is running. Terminate Fx, keep log file, restart Fx without environment variable, please.
If you use DebugView, you can see log for specific operations only by "Start Capture" and "Stop Capture" of DebugView. See bug 402793 comment #6. If you use DebugView, please set nsHttp:5 instead of timestamp,nsHttp:5 to avoid duplicated timestamp data by NSPR logging and DebugView.

    
    

    
  
Bjarne, could you summarize where we're at with this bug? Is there anything we can do to make this better, or is this simply just a bug in hotmail?
blocking2.0: beta1+ → beta2+

    
    

    
  
Uhmm...  yes. Comments after comment #165 seem contradictory.

Structure of the failing page seem to be similar to the old one as shown in comment #155. I.e. an (invisible) textarea containing the quoted email is a DOM-sibling of an iframe using it, but the iframe is "before" the textarea. Hence, the fundamental issue of the textarea loading after the onload-handler fires may not be fixed.

This is from a quick analysis - I need to dig deeper and probably also communicate with the hotmail team for details to conclude on this. I cannot reproduce the issue now though, so something seems to have improved.

    
    

    
  
Hotmail team explains that they have only pushed the new version to one cluster so far, which explains the variety in comments above. No ETA on full roll-out.

    
    

    
  
Since this problem began I have been using 3.5.1 hoping to "wait out" a resolution of the problem.  That was working up until about two days ago.

The problem is now affecting 3.5.1.  I have had correspondents send back ??? to me after I wrote a "reply" but they received a blank email.  Also, I have had the "reply" command send back the original writer's email but cut off my message in mid sentence.

The "sent" file does not keep the whole message that I wrote.  Whatever gets clipped in the REPLY mode also gets clipped in the SENT file.  So, when I spend an hour writing something, and hit "send," it disappears.  This is like the old days gang, of floppy disks and save your stuff every five minutes or you lose it forever.

I have been a dedicated Mozilla user since the product came out.  However, 90% of my email is handled through my hotmail account.  I can't conduct my personal or professional life with this lack of reliability.

Therefore today I just installed Chrome as my default browser.  I will continue to monitor the progress on this bug and hopefully come back as a Mozilla user when it is resolved.  The last time technical issues forced me off a browser was the Netscape Navigator way back in the 90s.   One thing led to another and I never went back, so I hope that doesn't happen here.

Greg N (written using Chrome)

    
    

    
  
Me too. Also occurs with 3.6.6!
Seems to be a big deal to fix this bug ...

As a workaround I am using IE7 (...) ;-)

--hfrmobile

PS: written with Firefox 3.6.6
PPS: hope this bug will be fixed soon :)

    
    

    
  
(In reply to comment #181)
> Since this problem began I have been using 3.5.1 hoping to "wait out" a
> resolution of the problem.  That was working up until about two days ago.
> 
> The problem is now affecting 3.5.1.  I have had correspondents send back ??? to
> me after I wrote a "reply" but they received a blank email.  Also, I have had
> the "reply" command send back the original writer's email but cut off my
> message in mid sentence.
> 
> The "sent" file does not keep the whole message that I wrote.  Whatever gets
> clipped in the REPLY mode also gets clipped in the SENT file.  So, when I spend
> an hour writing something, and hit "send," it disappears.  This is like the old
> days gang, of floppy disks and save your stuff every five minutes or you lose
> it forever.
> 
> I have been a dedicated Mozilla user since the product came out.  However, 90%
> of my email is handled through my hotmail account.  I can't conduct my personal
> or professional life with this lack of reliability.
> 
> Therefore today I just installed Chrome as my default browser.  I will continue
> to monitor the progress on this bug and hopefully come back as a Mozilla user
> when it is resolved.  The last time technical issues forced me off a browser
> was the Netscape Navigator way back in the 90s.   One thing led to another and
> I never went back, so I hope that doesn't happen here.
> 
> Greg N (written using Chrome)

Switch to Gmail.  Have gmail import and forward your messages from your Hotmail account.  You can even send them from your Hotmail address using Gmail.  I did this a few weeks ago, works perfectly.  Gmail is a better interface too, once you get used to it.

This bug is a problem with Hotmail's code, not Firefox's, so Hotmail has lost my business, not FF.

    
    

    
  
Per comment 164 this is a problem in Hotmail and they have acknowledged it and have a fix in hand. Over to evangelism to track the remainder of this issue.
Assignee: bjarne → english-us
blocking2.0: beta2+ → -
Component: Networking: Cache → English US
Product: Core → Tech Evangelism
QA Contact: networking.cache → english-us
Version: 1.9.2 Branch → unspecified

    
    

    
  
Just mencioned the best way to solve it:after using only Win for 10 years I've just tried 30 min ago Linux:no words,or may be one: smoooooth and faast. And of course you see the previous message when answering a hotmail mail.

    
    

    
  
Recent changes on Hotmail seem to have fixed it. At least, it's working flawless on my side. Using Win 7 Pro 32 bits, FF 3.6.8

    
    

    
  
Original bug reporter (well, one of them) here confirming the latest version of Hotmail no longer exhibits the problem for me.  All is well on both Mac OS X Snow Leopard and various NetBSD releases.

    
    

    
  
Cheng, Al: you guys OK to close this out based on reports of EPIC SUCCESS?

    
    

    
  
Since I was the one that started this thread many months ago, because I am totally helpless in this area, I'm fine with ending it.  The changes Hotmail made recently seems to be the cure.  Thank you to everyone that has helped along the way.
Michael Doyle

    
  
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: