Answered by:
IE's Slowness With Long Threads on Microsoft Forums

Question
-
Long threads on this website become very slow to display (as in locking up the browser for literally MINUTES). But the page displays finally DO complete if you're very patient, indicating it's not an infinite loop.
This is not a new problem, it's obvious to all and it's been discussed here before, with Microsoft's acknowledgement. But amazingly it has only been given minimal attention. Some forum updates have incrementally decreased the time to display long threads, but the problem remains, literally for years!
I believe it needs to be discussed further. It cannot be that Microsoft wants IE to work this badly on its own website. Certainly waiting for threads to display doesn't make our days any brighter.
Here's a fairly long thread you can try it on if you'd like to reproduce the problem for yourself:
Some observations:
- It takes MUCH longer (something like 10x longer) if you're logged-in than if you're logged out.
- Sometimes IE puts up a message that "Microsoft.com is not responding due to a long-running script". I've seen other browsers put up similar messages.
- Most times fairly quickly the page will partially render, but without the avatars, etc., then the avatars, points, etc. will fill in much later when the spinner stops, indicating the page display is done.
- Not every browser is equally slow, though all seem to be affected by whatever
near-infinite loop Microsoft has coded in the web script.
- The problem seems to be getting no better in the latest versions, even though they claim much faster script processing. It also seems worse on 64 bit OSs.
Observed logged-in times to display the thread at the link I provided above:
- Windows XP Pro, IE8:
Page initially went solid blank white.
27 seconds to display the page initially, coincident with a dialog: "A script is running slowly", "Stop this script"? I answered No.
64 seconds to display the avatars, names, points, etc.
- Windows Vista 32 bit, IE9:
2.6 seconds to display the page initially
32.4 seconds to display the avatars, names, points, etc.
- Windows Vista x64, IE9 (on a much less powerful workstation than the others here):
4.8 seconds to display the page initially
175.4 seconds to display the avatars, names, points, etc.
- Windows 7 32 bit, IE9:
3.2 seconds to display the page initially
31.0 seconds to display the avatars, names, points, etc.
- Windows 7 64 bit, IE9:
2.8 seconds to display the page initially
43.8 seconds to display the avatars, names, points, etc.
- Windows 7 64 bit, IE10 (RP):
2.6 seconds to display the page initially
59.4 seconds to display the avatars, names, points, etc.
- Windows 8 64 bit, IE10:
3.0 seconds to display the page initially
63.6 seconds to display the avatars, names, points, etc.
Since Microsoft doesn't seem to want to try to get to the bottom of this, how about we here have a go at figuring out what's happening using the various profiling and tracing tools? Wouldn't it be great to be able to browse here more quickly?
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" Options
- Edited by Noel Carboni Wednesday, February 13, 2013 6:04 PM formatting
Wednesday, February 13, 2013 5:58 PM - It takes MUCH longer (something like 10x longer) if you're logged-in than if you're logged out.
Answers
-
Thanks Noel. Only 11 secs? Yikes. Mine was 44 secs. Robert's was 67.
I have a small clue why. But first, I just noticed something. Robert brought our attention to those long yellow bars, one whose address contained the phrase Right Rail Announcement. Now today, I suddenly noticed this. Coincidence? Also, I was pretty entertained with Robert's figure of speech blind men feeling up the elephant, and mathematical use of terms like non-linear. Non-Linear? Heck, his 858 sec load-time delay is a singularity, that's what it is. : )
But speaking of non-linear. That's definitely the case, when we compare these statistics:
Your 11 sec appendChild script test time, versus your 57 sec Network Trace time. (11:57 ~ 20%)
My 44 sec appendChild script test time, versus my 102 sec Network Trace time (44:102 ~ 44%)
Roberts 67 sec appendChild script test time, versus his 858 sec Network Trace time (67:858 ~ 8%)
If we just consider ratios, Robert's script execution is best. Ok, more seriously, it's evident the appendChild calls have nothing to do with Robert's unusual, way excessive delay. Furthermore, I tested a VM with only 2 GB on my PC, and still got practically the same numbers I already cited. So, it doesn't seem like the amount of RAM has anything much to do with the delays any of us are seeing.
But still on this non-linear subject, did you notice the calls within decorateMessage (the major time consumer) are approximately multiples of the number of posts squared ? Yes, that's right, squared. There are 159 posts plus 1 OP in that long thread, 160 messages in total. Review this snapshot I had previously posted. I wondered why the common number was not exactly 160x160 = 25600. The common multiple in my snapshot, 24480, equals 160x153. 153. Hmmm. Well, I posted there 5 times. Subtract that from 160, arrive at 155. That's close to 153. What might this mean? Well, in decorateMessage, I suppose we can exclude me from voting for myself, or marking myself abusive. So that kind-of explains why the call count is less than 160x160. Except for the obvious question. Why would each message decoration require modification to every one of the 160 messages again? Do you see what I'm saying?
Anyway, to confirm that odd number 153 was reduced from 160 due to my posts in that thread, I logged in with a different LiveID which hadn't posted anything to that long thread. Here's the profiler snapshot viewed from that LiveID that hadn't posted there: snapshot. The common multiple 25280 = 160x158. So I'd say in general, the common multiple equals (total posts) x (total posts minus 2, minus your own posts).
Which brings me to my earlier clue about your 11 sec script time, Noel, or more generally, your quicker page loading times. You posted into that long thread about 33 times, so I'd predict your common multiple under decorateMessage would be only 160x(160-2-33) = 20000. No wonder your load time is faster. Cheater. ; )
So, Robert is right that there is something non-linear in the algorithm. The delay is dominated by decorateMessage, which makes nearly posts-squared calls. Naively (without looking at the sourcecode), it's puzzling why each post's decoration would cause every other post to get re-decorated (if that's what's going on). It seems like that must be what's happening. You'd think once is enough, wouldn't you?
- Edited by idle curiosityBanned Monday, February 18, 2013 2:44 PM
- Proposed as answer by Ed Price - MSFTMicrosoft employee Sunday, February 24, 2013 1:08 AM
- Marked as answer by Spencer Xi Wednesday, February 27, 2013 4:28 AM
Monday, February 18, 2013 1:56 PM
All replies
-
More info: Logged-in timings with other browsers...
- Windows 8 x64, Google Chrome 24.0.1312.57 m
2.6 seconds to initially display the page
8.2 seconds to show the avatars, names, points, etc.
- Windows 8 x64, Safari 5.1.7
Most times Safari would get caught in a loop apparently attempting to log in behind the scenes then error out. However once I got it to show that long thread:
1.8 seconds to initially display the page
9.0 seconds to show the avatars, names, points, etc.
- Windows 8 x64, Firefox 18.0.2
2.4 seconds to initially display the page
10.0 seconds to show the avatars, names, points, etc.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsWednesday, February 13, 2013 7:12 PM - Windows 8 x64, Google Chrome 24.0.1312.57 m
-
I have got to figure out how to remove Shockwave Flash from W8. It solved a similar problem in W7 with IE10.
C.f.
Note that Google Analytics was the problem function in that thread's test and TP did not block it. (Possible side issues to be aware of when testing other sites for this Shockwave Flash factor.)
I just did another Profiler in NAOM + ActiveX Filtering (but no TP) for the thread which is the subject of this thread
B 1 858,787.58 0.00 http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.7.1.min.js 2
ICIM my test procedure was Run... iexplore.exe -nohome -extoff F12 (Profiler would not start. So switched back to IE and did Alt-V,p.) Profiler started for that. Then I pasted the test link in the Address bar and hit Enter. Stopped Profiler after fan noise subsided.
FYI
Robert
---- Proposed as answer by Ed Price - MSFTMicrosoft employee Sunday, February 24, 2013 1:07 AM
- Unproposed as answer by Noel Carboni Sunday, February 23, 2014 8:48 PM
Wednesday, February 13, 2013 10:17 PMAnswerer -
Thanks for the info, Robert.
This seems like a bug that's triggered by whatever happens during (or is required by) the automatic login, rather than a simple performance issue - though the latter is implied by the fact that it finally does finish seemingly without errors.
What surprised me was that a few months ago, when I last looked at this issue, I saw that the other browsers were being stalled similarly by long threads on Microsoft's site - some for longer than IE.
Now, today, I tested all the other browsers - latest versions. Each and every one of them displayed the entire thread linked-to above in 10 seconds or less. The only trouble was that Safari has some trouble coordinating the auto-login and gets into a loop, which also happens on iPad and iPhone, and seems completely separate from the issue we're discussing here.
That says that the development teams at each of the other browser organizations have figured the problems rendering this site out and solved them. Only Internet Explorer is out on a limb still with a problem - on Microsoft's own web site! Worse yet, on a 64 bit Windows 8 system IE10 takes fully twice as long as IE9 on a 32 bit Vista system. This alone ought embarrass the IE team into fixing this!
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsThursday, February 14, 2013 4:34 AM -
This seems like a bug that's triggered by whatever happens during (or is required by) the automatic login, rather than a simple performance issue
Ok. This was after installing some updates, including one for IE and one for Shockwave Flash. Normal About:Blank was my starting point.
B 1 851,592.19 1.00 http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.7.1.min.js 2
then Ctrl-F5
B 1 844,485.42 0.97 http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.7.1.min.js 2
So I guess login does account for some of that but not most of it. Also, as idle curiosity noted this is not wall time. So performance was even more ridiculous than this implies.
I still need to figure out how to get rid of Shockwave Flash without following the absurd suggestion that I treat the problem as a damaged user profile.
---Thursday, February 14, 2013 5:22 AMAnswerer -
Stop responding because of a long script. As soon as I hit stop script the page loads right away.
- Proposed as answer by Ed Price - MSFTMicrosoft employee Sunday, February 24, 2013 1:07 AM
- Unproposed as answer by Noel Carboni Sunday, February 23, 2014 8:38 PM
Thursday, February 14, 2013 5:54 AM -
@Robert. I just tried disabling Flash
See the W7 experience? Only removing the Shockwave Flash add-on changed the symptom. Disabling it did not help. A difference is that in W7 I could see the add-on installed and remove it. My next tack will be trying an Adobe removal tool.
Regarding Stop, I hinted that it just makes things worse and the only Stop that ever works for me in IE since IE8 is Alt-V,p. E.g. pressing Esc is usually ignored and clicking on the Stop button (when it is visible) is similarly ineffective.
If removing Flash doesn't help I'll switch to a VM. C.f. http://www.modern.ie/en-us
---
Thursday, February 14, 2013 2:25 PMAnswerer -
How does Shockwave Flash get installed on these systems to begin with?
I clamp down on the installation of Add-ons from the Internet Zone very early in my system setup. The only page IE ever sees before that's done is Microsoft's own default home page (what is that, MSN?). Either it's installed as part of the system setup or it's installed during that first visit to Microsoft's page.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsThursday, February 14, 2013 3:08 PM -
How does Shockwave Flash get installed on these systems to begin with?
It's embedded in the OS with IE10. In W7 it gets installed with IE10 fortunately separately so it can be uninstalled and since uninstalling it fixed a severe performance problem there that is why I am fixated on either fixing it or getting rid of it in W8.
I just found out there is a Control Panel applet for it but even for my admin account it is non-functional, e.g. doesn't show the version of Flash which is now installed (in Advanced tab) and gives me no control over updates (though I suppose it is inheriting my Windows Update preference to be notified).
http://support.microsoft.com/kb/2720221?wa=wsignin1.0
BTW I am posting this using my admin account, so completely different user profile, and it gets the same Profiler results with my other Live ID. (I switched in order to make this post.)B 1 845,085.51 0.00 http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.7.1.min.js 2
That was starting from the forum message list because this account doesn't have any History or Favorites to use to get there from.
But you're right about the Sign-in factor, before I signed in this was the biggest single item listed
loadDataSuccess 1 3,084.32 31.00 http://widgets.membership.s-msft.com/v1/widgets.js?brand=Technet&lang=en-US&ver=4.9.0.0 46
http://www.adobe.com/software/flash/about/
shows in spite of that update that WU gave me yesterday that I DO NOT (?) have the latest version installed
Version Information box shows: You have version 11,3,379,14 installed
From
<quote>
The table below contains the latest Flash Player version information.
Internet Explorer (Windows 8) 11.6.602.167
</quote>
WTH? How did idle curiosity "remove the Flash updates so it reverts to the base version"? Presumably by KB number? But a search in Support finds nothing about it?Oh. There was one in September.
http://technet.microsoft.com/en-us/security/advisory/2755801
(via BING search for
flash "windows update" site:support.microsoft.com
)Was that the latest? Is it listed as a product in the TechNet Security Bulletin Search Tool?... No. But why is this listed only for IE10 and not W8? (EDIT)
http://technet.microsoft.com/en-us/security/bulletin/MS13-009
Still no sign of "the Flash update" there either except as a link to Adobe from the September bulletin
http://www.adobe.com/support/security/bulletins/apsb13-05.html
<quote>
Flash Player installed with Internet Explorer 10 for Windows 8 will automatically be updated to the latest Internet Explorer 10 version, which will include Adobe Flash Player 11.6.602.167 for Windows.
</quote>
Oh. Here it is. I had to use systeminfo an an Administrator cmd window to find this. Apparently the last update that I received yesterday.
http://support.microsoft.com/kb/2811522
So that at least explains the version I have but not why it is so old. Typical of WU/AU being so slow in validating third-party updates though.
I'm wondering if instead of trying to remove Flash I should try using the latest and greatest from Adobe. E.g. perhaps doing that would have a similar beneficial effect on IE10 performance in W8 that removing it from W7 had?
BTW am I missing some change management tools which would make this analysis more efficient? dism perhaps?
---
Edit: I don't know if I missed it or if it changed but I now see MS13-009 listed with both IE10 and W8. Sorry for this confusion.- Edited by Robert Aldwinckle on forumsEditor Friday, February 15, 2013 5:12 PM EDIT
Thursday, February 14, 2013 5:43 PMAnswerer -
Regarding Stop
Serendipity:
http://support.microsoft.com/kb/2792100
<quote>
2807919 (http://support.microsoft.com/kb/2807919/ )Internet Explorer 10 freezes when you click "Stop script" on a script freeze dialog box in Windows 8 and Windows Server 2012 </quote>
I can't remember seeing so many useful changes in an update before. E.g. not all are obstructive, security-oriented ones here.
Thursday, February 14, 2013 5:54 PMAnswerer -
I'm wondering if instead of trying to remove Flash I should try using the latest and greatest from Adobe. E.g. perhaps doing that would have a similar beneficial effect on IE10 performance in W8 that removing it from W7 had?
It's worse.
B 1 1,078,750.38 0.00 http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.7.1.min.js 2
and the Control Panel applet is still not recognizing the change of version.
Clearly the thing was never hooked into the OS properly in the first place.
BTW after the fan got going I decided to start a Network Capture too. Nothing happened there until the end when this turned up
URL Method Result Type Received Taken Initiator Wait Start Request Response Cache read Gap
http://widgets.membership.s-msft.com/v1/user/usercard/?id=<REMOVED>&lang=en-US&brand=Technet&callback=jsonp_loadUserData0 GET 200 application/json 82.31 KB 0.78 s <script> 0 63 515 202 0 1125485That looks familiar, e.g. see my "before I signed in" result above.
Now I'm wondering if my ReceiveTimeout of 8 minutes is somehow having a effect on all this, e.g. maybe provide an explanation for why my wait is so much longer than anyone else's? Then that would mean that there is at least one request somewhere in the message stream which is being ignored but then that I don't think that would account for my fan noise. I suspect the DOM is doing something but I don't know how to trace it.
Blackbox troubleshooting of object-code only object-oriented systems is so,... so... (I don't know the right word for my frustration.)
---Thursday, February 14, 2013 7:17 PMAnswerer -
Looks like "Flash factor" is a red herring.
Using IE10 on W7 with the latest updates but with no Flash at all:
B 1 816,844.67 0.00 http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.7.1.min.js 2
Now what?
---
- Edited by Robert Aldwinckle on forumsEditor Thursday, February 14, 2013 11:44 PM This editor is still broken.
Thursday, February 14, 2013 11:41 PMAnswerer -
By the looks of it and I'm not done, I think I know what is going on now.
The link styles sheet cant be loaded. So the loop to try to apply the script to every post is being varified and fails.
So I varified some things and there are so many i'd need access to the root directory to even get any work done. Like I mention their is a coding error that is causing the script not to load. I think it has to do with styles. To begin with. I think it has to do with quoting and color. There are so many errors in the coding and to debug all the errors it would take a team of 7 or 8 to work on each area of the code to fix it.
this is one area and I can see the same error code that is in the picture before the aborted script.
- Edited by colakid Friday, February 15, 2013 12:15 PM
Friday, February 15, 2013 11:35 AM -
Noel,
Just for your information.
I have IE10 preview in a Win7-64-bit system. Yes, it is too slow to display a long thread on this forum. However, my delay is in the 20-25 sec frame, not as long as yours.
However, Firefox 18.02 is very fast, even faster than Chrome 24. Both of those browsers display the page in 2-3 sec, even faster on occaasions.
Friday, February 15, 2013 5:43 PM -
Thanks for all the additional info.
Clearly there are complex things going on. Even on the same system one sees enough variance in timings to realize that there are some components of the problem that are dependent on external factors - possibly random locations (e.g., from a wild pointer) or even something to do with the information from and timing of the server(s).
Beyond the slowness, I've seen that the path through which one gets to a particular page changes the way the page is displayed, which puts the CSS management in question, as colakid has pointed out. I've never quite figured out how to reproduce that cross-page coupling, but I've definitely seen it.
This is Microsoft's own "get our users do our customer support for us" web site, right?
Why wouldn't Microsoft want to put enough effort into it to actually make it work right?
This is Microsoft's own browser, which no doubt they feel has some indirect value to Microsoft or they'd stop working on it.
Why wouldn't Microsoft want to actually make it work right in light of the errors on their own web site?
Like I said, the problem has been obvious for years.
Have talented people taken to avoiding working for Microsoft? Surely it's not because there's not enough money.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsFriday, February 15, 2013 6:22 PM -
ADRz, out of curiosity, do you have a fairly powerful (Sandy Bridge or Ivy Bridge) processor? Seems to me the stall time is at least somewhat related to core speed. But it may be related to other factors, either on the local system or something to do with the server.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsFriday, February 15, 2013 7:02 PM -
ADRz, out of curiosity, do you have a fairly powerful (Sandy Bridge or Ivy Bridge) processor? Seems to me the stall time is at least somewhat related to core speed. But it may be related to other factors, either on the local system or something to do with the server.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" Options
Yes, my system utilizes the most recent processor, it has lots of memory and SSD drives. I hardly ever rely on IE10 mainly because it lacks an inline spell checker (MS removed it after IE8). My main browser is Firefox but I utilize Chrome, too.Saturday, February 16, 2013 12:27 AM -
Your high core speed probably explains why you're seeing lower delays. But I don't think the right answer is to have to buy God's own computer to run IE on Microsoft's site at a reasonable pace.
I thought one of IE10's claims to fame was that it adds a spell checker. Seems to check the spelling of stuff I type. Am I missing what you mean by "inline"?
I can''t say I remember a spell checker being in a prior version of IE, but my memory is like a steel trap. Hardly anything comes out. :-)
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsSaturday, February 16, 2013 3:55 AM -
Your high core speed probably explains why you're seeing lower delays. But I don't think the right answer is to have to buy God's own computer to run IE on Microsoft's site at a reasonable pace.
I thought one of IE10's claims to fame was that it adds a spell checker. Seems to check the spelling of stuff I type. Am I missing what you mean by "inline"?
I can''t say I remember a spell checker being in a prior version of IE, but my memory is like a steel trap. Hardly anything comes out. :-)
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsBoth Chrome and Firefox have inline spell checkers which means that they underline misspelled words while you type. My memory is not particularly great either, but I am almost certain that there was in inline spellchecker in IE until version 7 or 8 (not sure). Surveys showed that many users abandoned IE mainly because of the lack of an inline specll checker.
Now, although IE and this forum's threads are mismatched, I have found incompatibilities with Firefox and Chrome in a variety of other sites. I think that the Microsoft sites are hampered by the fact that they must maintain compatibility with earlier, non-standards compliant versions of IE, including IE 6.
Saturday, February 16, 2013 4:16 AM -
What I found is that IE times are pretty much independent of which tag is being searched. It took about 40 secs in both tests shown above.
In my case it was 67. And I forgot to close the message window when I retried. That one took 70 and blacked the screen?
This is starting to seem like the group of blind men feeling up the elephant... <eg>
In my case, I still think there is some kind of network component to my extreme delay, possibly due to my ReceiveTimeout of 8 min.
One thing I haven't mentioned yet is observing Network Capture. It stalls for most of the delay for 4 XMLHTTPRequests
URL Method Result Type Received Taken Initiator Wait Start Request Response Cache read Gap
/Forums/en-US/rightrailannouncement/Technet/7df09344-598d-4d00-80ea-51b8d79f051a?forumName=w8itprogeneral&rnd=0.8134895451656852 (Pending...) (Pending...) (Pending...) (Pending...) (Pending...) XMLHttpRequest 51964 16 0 0 0 702
/Forums/en-US/user/mylinks?forumId=49868211-6c8e-41aa-96e3-a410a09cab22&forumName=w8itprogeneral&rnd=0.1731782140841911 (Pending...) (Pending...) (Pending...) (Pending...) (Pending...) XMLHttpRequest 51980 0 0 0 0 702
/Forums/en-US/search/RelatedThreadsByThread?threadTopic=What%20Windows%208%20is%20doing%20to%20people&threadId=3baf6cb4-e21f-41d8-95f7-a06f4fc12076&rnd=0.8478871725608346 (Pending...) (Pending...) (Pending...) (Pending...) (Pending...) XMLHttpRequest 51980 0 0 0 0 702
/Forums/en-US/w8itprogeneral/thread/3baf6cb4-e21f-41d8-95f7-a06f4fc12076/stats?createdOn=01%2F09%2F2013%2005%3A32%3A47&lastReplyOn=02%2F14%2F2013%2005%3A45%3A41&replies=159&views=2531&helpfulVotes=44&rnd=0.877230855172709 (Pending...) (Pending...) (Pending...) (Pending...) (Pending...) XMLHttpRequest 51996 421 0 0 0 265and then about 20 minutes later after nothing has happened according to ProcMon (but both Task Manager and Resource Monitor and my fan tell a different story) they all get filled in
URL Method Result Type Received Taken Initiator Wait Start Request Response Cache read Gap
/Forums/en-US/rightrailannouncement/Technet/7df09344-598d-4d00-80ea-51b8d79f051a?forumName=w8itprogeneral&rnd=0.8134895451656852 GET 200 text/html 0.52 KB 858.14 s XMLHttpRequest 51964 16 858130 0 0 6412
/Forums/en-US/user/mylinks?forumId=49868211-6c8e-41aa-96e3-a410a09cab22&forumName=w8itprogeneral&rnd=0.1731782140841911 GET 200 text/html 2.05 KB 858.13 s XMLHttpRequest 51980 0 858130 0 0 6412
/Forums/en-US/search/RelatedThreadsByThread?threadTopic=What%20Windows%208%20is%20doing%20to%20people&threadId=3baf6cb4-e21f-41d8-95f7-a06f4fc12076&rnd=0.8478871725608346 GET 200 text/html 5.07 KB 858.14 s XMLHttpRequest 51980 0 858130 16 0 6396
/Forums/en-US/w8itprogeneral/thread/3baf6cb4-e21f-41d8-95f7-a06f4fc12076/stats?createdOn=01%2F09%2F2013%2005%3A32%3A47&lastReplyOn=02%2F14%2F2013%2005%3A45%3A41&replies=159&views=2531&helpfulVotes=44&rnd=0.877230855172709 GET 200 text/html 0.83 KB 858.13 s XMLHttpRequest 51996 421 857709 0 0 6396858
and the rest of the trace is recorded.
858 seconds is 14.3 minutes, so I still have to account for 6 minutes but clearly that is a significant portion of the elapsed time. What was it doing?
Is this related to colakid's missing CSS file?
Oops. That was with Enable Native XMLHTTP Support being unchecked. I had been experimenting with that and obviously forgot to turn it back on. I don't think it makes that much difference but I will retry. What made more difference IIRC is experimenting with other Browser Mode and Document Mode settings but also only fractionally--nothing which can explain my extreme results.
I think I'm going to have to find another test case, one which demonstrates the problem but which doesn't require such an extreme amount of time for each trial. Even this thread might do. Your script took about 15 s here. Now 18 after enabling Native XMLHTTP Support? What next? ; \
---
- Edited by Robert Aldwinckle on forumsEditor Sunday, February 17, 2013 8:49 AM This editor is still broken.
Sunday, February 17, 2013 8:47 AMAnswerer -
Maybe the way IE implements things yields performance advantages in more usual page rendering and scripting activities. But in the special case of these extra-long threads, they're practically hanging during loading.
I agree and from my results versus yours for timing a linearly complex algorithm we now have a factor (e.g. my 70 versus your 40) which probably is being exponentially multiplied due to the non-linear complexity of whatever the algorithm is that they are using in that ajax code and that may account for my 20 minutes versus everyone else's faster rendering. If I still had my trusty HP-27 I'd be tempted to doing some calculations on that tack. I bet with enough datapoints we could estimate what that complexity really is. ; )
But what can they possibly be doing which would require an algorithm with such implied complexity? Shouldn't it all be linear?
Maybe I should try only starting the Profiler once the Network Capture shows those XMLHTTPRequest pending? That might highlight that algorithm better.
If poster info would show up quickly I would not mind using Stop, e.g. to forgo the right side bar which I rarely look at and in the case of My Forum Links I could open easily enough using smaller pages. I wonder why that (poster info) takes so long to show up? Seems like that should be linear too. In fact, I keep forgetting that there is a workaround for knowing poster info even though it isn't visible if Stop is pressed or if the page is returned too quickly (as sometimes inexplicably happens): use the Developer Tools, Find tool and read it from the source. This reminder may be enough for me to start using it more.
---Sunday, February 17, 2013 5:18 PMAnswerer -
Well, in that F12 Dev Tools Network timing chart you're referring to, those four extremely long yellow bars represent Ajax calls. (I looked it up). They're not the cause of the delay. They're the effect of it.
I see only 3 long bars, but to confirm your observation that the long bars are the result of a long running script locally, I fired up Fiddler (a web request tracing tool found at http://www.fiddler2.com/fiddler2/). Sure enough, there were three requests just prior to the long delay, BUT the responses were received immediately, the server did not delay. Somewhere likely in the processing of those three responses (or possibly just coincidentally) a script delayed IE from doing anything else.
Here are some wide screen grabs showing those three requests and a summary that shows the timing.
IE10 F12 Network Trace Showing 3 Requests with Very Long Delays
Fiddler Capture of First Long Request
Fiddler Capture of Second Long Request
Fiddler Capture of Third Long Request
Fiddler Capture of Next Request Immediately Following the Almost 1 Mnute Delay
Fiddler Relative Timing Showing the First Three Requests Completing in a Small Fraction of a Second
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" Options- Edited by Noel Carboni Monday, February 18, 2013 1:23 AM Corrected last link
Sunday, February 17, 2013 5:43 PM -
Notably, the thing that's not done prior to the delay is the filling in of the Avatars and other information about each user for each post, presumably by finding hundreds of elements in the DOM and filling them in. Of course, as threads grow longer this has to be done more and more times.
I'm falling in line with idle curiosity above, who has shown above that this activity can consume a huge amount of CPU time.
The fact that augmenting an existing document object model with updated information can busy a modern computer for literally MINUTES at a time is testament to the horrible inefficiency of the object-oriented processes when coupled with interpreting scripts.
But there is still another factor: We haven't explained why it should be SO much slower when logged-on to the web site than when not logged-on. Perhaps a next step is to compare the traffic of the two conditions and see what's different.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" Options- Edited by Noel Carboni Sunday, February 17, 2013 5:55 PM typo
Sunday, February 17, 2013 5:54 PM -
Sorry about the link issue. I think it's fixed now.
I did see what you had highlighted (that's what made me think to confirm what you did), and I just didn't run the script myself since I trusted what you had put up. But I have just done so now just for good measure:
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsMonday, February 18, 2013 1:32 AM -
>testing rightrail request
Glad we got someone's attention!
I had sensed some kind of non-linear pattern, but I'm very impressed that you took it to the next level and actually figured out a numeric relationship. Couple in the fact that we're seeing the times change radically when logged-in vs. logged-out, and we strengthen the possible relationship between the particular user and his own posts vs. posts by others.
Generalizing, it's not hard to imagine a piece of script code that does something to (or searches for something in) every post in the thread, and which runs once for every post in the thread, and further, it's not hard to imagine it taking a different path (not doing the thing that takes a long time) when the post is from the logged-in user. Further, it's possible to imagine that snippet of script avoiding running when no user is logged-in, making logged-out thread update times linear rather than a modified square law. We tend to think "why would someone write code to do that?", but maybe it's not serving a practical purpose. Could just be a bug.
Let's test the theory on some long threads I've both participated in, and not. All times logged-in, same forum subsection.
41.2 seconds, 152 posts, 33 of them mine (the thread idenfied in the OP of this thread)
25.4 seconds, 118 posts, 0 of them mine.
16 seconds, 102 posts, 4 of them mine.
6.4 seconds, 60 posts, 0 of them mine.
That's all the long threads I could come up with in 50 pages of Win8 forum threads, and not surprisingly I've run out of time at this moment to continue this post.
The above measurements do seem to fit quite well into your theory, idle curiosity. Whatever "bad thing" the script is doing appears to take between 1 and 2 milliseconds on my system. There's definitely a "number of posts squared" factor in there, so the folks debugging this should look for a script that runs once per post and has a loop that does something with each of the posts in the thread.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" Options- Proposed as answer by Ed Price - MSFTMicrosoft employee Sunday, February 24, 2013 1:08 AM
- Marked as answer by Spencer Xi Wednesday, February 27, 2013 4:28 AM
- Unmarked as answer by Noel Carboni Sunday, February 23, 2014 8:39 PM
- Unproposed as answer by Noel Carboni Sunday, February 23, 2014 8:49 PM
Monday, February 18, 2013 3:26 PM -
FYI, the IE10 release shows no difference in speed whatsoever.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsSunday, March 3, 2013 12:02 AM -
Is there some reason to think that Microsoft is smart enough (or cares enough) to implement a change even when their nose is placed squarely on the problem and even if they're given a solution?
I believe there must be folks there who think that it's a feature that really long threads become untenable. If allowed to just grow ad infinitum, an "[insert product here] Makes My Eyes Bleed" thread with 11.2 million "me too" responses might be embarrassing for the pointy haired bosses.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsSaturday, February 15, 2014 10:30 PM -
Something must've escaped me.
Don't overlook the possibility that something might have been fixed. There were an unusual number of GDR non-security-related fixes released recently.
C.f.
http://support.microsoft.com/kb/2909921
BTW notice the last one in that list? <eg>
FWIW I thought if the forum search worked better I could have closed out a number of long, contentious threads simply by using that list as a guide and source of keywords. Bizarrely a Microsoft search of Support still does not find that article by name or number but I now have it memorized, even though it only takes Alt-x A in IE to see it again.
Robert Aldwinckle
---Sunday, February 16, 2014 4:58 AMAnswerer -
Gotta love object oriented systems. Nice little demo.
One man's "preserved element" is another's "memory leak".
When can an object be discarded? "Later sometime" is tough to implement. Same reason my garage is full of junk and I can't fit a car in there.
I'm not sure I've made the connection between that issue and what makes the forum slow on long threads, though. Did I miss a key detail?
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" Options
- Edited by Noel Carboni Sunday, February 16, 2014 8:47 AM
Sunday, February 16, 2014 8:45 AM -
What do you think of this? online demo
I'd like to tell him. I'm sure that'd make his day. Hmm. I'm going to have to figure out how to start a new thread there without causing a troll riot.
FWIW it looks like all 3 of you essentially agree. What is obscuring truth and value in that thread is all the ridiculous posturing that is going on. But I don't know enough about it even to think if it is something which would be reported on Connect, e.g. in order to try to raise an opinion there.
BTW why would you need to start a new thread? It's not locked.
Robert Aldwinckle
---Sunday, February 16, 2014 4:38 PMAnswerer -
BTW why would you need to start a new thread? It's not locked.
You may be talking about something different than Roy is; the thread to which he refers sure looks locked from here.
It's also a shame that the thread on FTP access problems from IE ended up locked. All the folks who were interested in using FTP sites from IE - including the one who was delusional about having no problem - would have benefited from a post on the end of that one announcing the update that made the "No Such Interface" problem go away (though it still doesn't work quite like it used to back when an OS was an OS and not some toy).
Thing is, it seems to take this kind of escalating debate in order for anyone in the unthinking behemoth that is Microsoft to even take notice of their problems. It's not healthy!
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" Options- Edited by Noel Carboni Sunday, February 16, 2014 6:11 PM
Sunday, February 16, 2014 6:07 PM -
Monday, February 17, 2014 4:16 AM
-
Well. What do you think of this? IE's test5 (innerHTML) is substantially faster than its other tests 1-4. That was unexpected.
It is still showing a multiplier that reflects the power of my CPU--which as we have seen affects non-linear algorithms exponentially.
Test 1: 1282 ms
Test 2: 1267 ms
Test 3: 1208 ms
Test 4: 1234 ms
Test 5: 208 ms
This is on W8.1. I'll try to remember to retest on W7.1
Robert Aldwinckle
---Friday, February 21, 2014 5:02 AMAnswerer -
I think it's excellent that you're gathering testing data in this way.
I'm sorry I haven't been back here to contribute before now.
IE11 on Win 8.1, "Run test in onscreen div (above)":
Test 1: 797 ms
Test 2: 839 ms
Test 3: 910 ms
Test 4: 877 ms
Test 5: 117 ms
IE11 on Win 8.1, "Run test in DocumentFragment div":
Test 1: 793 ms
Test 2: 813 ms
Test 3: 800 ms
Test 4: 763 ms
Test 5: 109 ms
Firefox 27.0.1 on Windows 8.1, "Run test in onscreen div (above)":
Test 1: 25 ms
Test 2: 25 ms
Test 3: 33 ms
Test 4: 34 ms
Test 5: 17 ms
Firefox 27.0.1 on Windows 8.1, "Run test in DocumentFragment div":
Test 1: 23 ms
Test 2: 23 ms
Test 3: 20 ms
Test 4: 21 ms
Test 5: 15 ms
I don't have Chrome installed on my main workstation. But I can provide some data points from a browser not tested above...
Safari 5.1.7 on Windows 8.1, "Run test in onscreen div (above)":
Test 1: 13 ms
Test 2: 14 ms
Test 3: 18 ms
Test 4: 19 ms
Test 5: 66 ms
Safari 5.1.7 on Windows 8.1, "Run test in DocumentFragment div":
Test 1: 12 ms
Test 2: 13 ms
Test 3: 15 ms
Test 4: 15 ms
Test 5: 16 ms
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" Options
- Edited by Noel Carboni Friday, February 21, 2014 1:14 PM
Friday, February 21, 2014 1:11 PM -
By the way, I thought I had made a mistake at first in copying the wrong numbers, but the mouseovers in the above don't differentiate between which kind of test is run. Compare this screen grab with the first set of numbers above...
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" Options- Edited by Noel Carboni Friday, February 21, 2014 1:19 PM
Friday, February 21, 2014 1:17 PM -
Care for some numbers from IE8 on Windows XP Pro (in a VM)?
IE8 on Windows XP SP3, "Run test in onscreen div (above)"
Test 1: 532 ms
Test 2: 562 ms
Test 3: 563 ms
Test 4: 562 ms
Test 5: 172 ms
IE8 on Windows XP SP3, "Run test in DocumentFragment div"
Test 1: 515 ms
Test 2: 547 ms
Test 3: 516 ms
Test 4: 515 ms
Test 5: 141 ms
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsFriday, February 21, 2014 1:26 PM -
Yet another different combo...
IE11 on Windows 7 x64 (in a VM), "Run test in onscreen div (above)"
Test 1: 841 ms
Test 2: 809 ms
Test 3: 871 ms
Test 4: 1024 ms
Test 5: 131 ms
IE11 on Windows 7 x64 (in a VM), "Run test in DocumentFragment div"
Test 1: 1179 ms
Test 2: 1199 ms
Test 3: 1158 ms
Test 4: 1021 ms
Test 5: 133 ms
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsFriday, February 21, 2014 1:34 PM -
retest on W7.1 (with IE11)
Test 1: 1654 ms
Test 2: 1809 ms
Test 3: 1664 ms
Test 4: 1815 ms
Test 5: 272 ms
Test 1: 1727 msTest 2: 1524 ms
Test 3: 1528 ms
Test 4: 1514 ms
Test 5: 254 ms
ICIM that was the 5th tab I had open.
Robert Aldwinckle
---Saturday, February 22, 2014 4:27 AMAnswerer -
Thanks Noel.
Close, except for Safari, where I get those astounding numbers you cited only when the "Hello World!" string is disabled. Maybe that's how you had that one config'd inadvertently?
I wasn't fooling with those settings, but I re-tested just to be sure and got pretty much the same numbers.
Regarding workstation performance, it's not really terribly much faster with single-threaded activities than less lofty systems, but it really shines when you try to load it up with a lot of work simultaneously. There's just a lot of parallel hardware on tap.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsSaturday, February 22, 2014 5:19 AM -
showing a multiplier that reflects the power of my CPU
IE11 on WinRT 8.1
Test 1: 1301 ms
Test 2: 1625 ms
Test 3: 2819 ms
Test 4: 1851 ms
Test 5: 2154 msTest 1: 2145 ms
Test 2: 1381 ms
Test 3: 2072 ms
Test 4: 1780 ms
Test 5: 2066 msWith Hello World checked
Test 1: 2925 ms
Test 2: 1770 ms
Test 3: 4325 ms
Test 4: 1980 ms
Test 5: 3370 msTest 1: 2872 ms
Test 2: 1668 ms
Test 3: 4383 ms
Test 4: 1729 ms
Test 5: 2175 ms(On my Surface 2. Having finally got it connected, I couldn't resist. <eg>)
Robert Aldwinckle
---- Edited by Robert Aldwinckle on forumsEditor Sunday, February 23, 2014 3:21 PM This editor is still broken.
Sunday, February 23, 2014 3:14 PMAnswerer -
I think the lack of consistency between measurements is why folks interested in real-time programming tend to shy away from object-oriented implementations.
But it seems that, even with object-orientation, Microsoft's competitors in browser implementation have figured out fundamentally better ways to implement DOM management, which - reiterating - is rather astounding since this makes Microsoft's own technical forum site perform incredibly poorly with Microsoft's own browser. Clearly no one who could effect positive change gives a damn.
I keep telling myself Microsoft must be posturing, positioning, preparing us psychologically for some future phoenix-like resurrection of their technological excellence.
But the resurrection doesn't come, and I'm grimly reminded of the old adage, "never attribute to malice that which can be explained by incompetence".
Here I look at this post, proofreading, using a 3rd party application from the 1990s to vocalize it, and noting that the scroll thumbs in IE11 have to be darkened by my own overriding CSS commands in order to make them usable... Soon, this thread will become so long as to make adding comments to it unwieldy, then we'll be forced to move on to other things that serve to illustrate Microsoft's mediocrity.
Sigh.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsSunday, February 23, 2014 8:32 PM -
As though to sweep the problem under the proverbial rug, I noticed this thread had been marked as having been answered (I just corrected that, with apologies to any who have lost points as a result).
In the English language I learned to speak, "Microsoft's slow browser performance" being "answered" would imply that either:
- The problem was found / fixed.
- An acceptable workaround had been provided
Since we neither have an answer nor an acceptable workaround (noting that I prefer IE over alternative browsers) this thread needs to remain unanswered, and indeed raised again into the consciousness of anyone on the IE team who can actually understand it.
What's incredible is that Microsoft's own people proposed and marked the answer. That's just sad. :-(
Embrace excellence, people. The alternative isn't becoming.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsSunday, February 23, 2014 8:47 PM -
I guess the IC Answer is immortalized, because it's invisible to me. I don't remember what that post said. Maybe it WAS "The Answer".
As recently as a year ago, when I first posted this thread, I still had some hope that Microsoft - if shown what's wrong - would potentially work to fix the problem
Perhaps there's a chance of that still, but honestly - speaking figuratively - I sense no one's home there any longer. They've been making moronic move after moronic move. It's as though all they have on the job are high schoolers and corrupt self-serving managers. Roy, I realize your threshold of tolerance of Microsoft's stupidity occurred quite a while back, but mine's finally been exceeded and I seem to be more and more understanding your point of view.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsMonday, February 24, 2014 1:08 AM -
Humph indeed. I read IE11 as over 500x slower at the Inner <#text> writes. To put it in perspective, that's in the same realm of performance difference as an 80286 vs. a Xeon E7.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" Options- Edited by Noel Carboni Monday, February 24, 2014 4:18 AM Made the wide image into a link
Monday, February 24, 2014 4:11 AM -
You might want to reduce the Size N value from default 20 to, say, 10 first. Then maybe 15.
The IE curve is kind of steep.
Yikes! 20 minutes for 20!! It started off so slowly I couldn't tell if I had actually clicked the button hard enough. E.g. no busy ring indicator anywhere that I could see. I just left it and went away to do other stuff.
BTW I have rebuilt my TouchSmart with a W7sp1 Pro image and reapplied all available updates (153). Then it was automatically(?) updated to IE10, with an option to install IE11 which I haven't taken yet. The only unusual thing about it may be that I still haven't been able to activate it. An escalation engineer will fix that for me tomorrow. Would that slow it down?
Robert Aldwinckle
---Tuesday, March 4, 2014 8:30 PMAnswerer -
Sizing the window (or scrolling it controllably) after having displayed all the little boxes with smileys became a bit of a challenge too.
Another few data points showing IE11 to be some 800x slower than the others. IE seems to be thrashing harder on my system than on yours for this test.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsTuesday, March 4, 2014 11:05 PM -
Did you run the demo from your desktop? We saw earlier that doing that causes IE to perform really poorly. I don't know why, but I guess it's got something to do with the security Zone. Why that matters I haven't a clue. But I just ran the demo from my desktop and sure enough, it took about 9 minutes.
Clearly not - I ran it directly from your link. The URL is showing in the screen grab.
But there is certainly a mysterious additional influence here in the timing. I believe you could well be right about it having to do with security. Hey, a browser that people give up on and go do something else out of frustration is almost certainly more secure than one that takes them immediately to a malware site. ;-)
By the way, since we're talking about incredibly slow programs - regarding that desktop search, try the freeware program grepWin by comparison to Windows Search. It actually produces rigorous results in much less time than Microsoft's debacle.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsWednesday, March 5, 2014 10:02 AM -
Thinking more on this incredible slowdown... I'm not using Enhanced Protected Mode, but almost NOTHING is allowed via my Internet zone settings, save for running scripts. I have blocked scripts from doing most things, including accessing browser controls. I'm guessing there's something that happens deep inside the object model accesses in that condition that may not happen when default settings are used. I can't say why that should affect this test where it didn't the earlier one.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsWednesday, March 5, 2014 10:23 AM -
It's a useless forum indeed on which reasonable, polite technical discussion is censored / deleted. :-( -NoelSunday, March 30, 2014 5:53 PM
-
It also doesn't work worth a damn with an iPad. -NoelSunday, March 30, 2014 5:54 PM
-
It also doesn't work worth a damn with an iPad. -Noel
Even if you Sign out?
Robert Aldwinckle
---Monday, March 31, 2014 3:32 PMAnswerer -
Well I did read the entire thread but TechNet has many issues ;)
Monday, March 31, 2014 10:09 PM -
It also doesn't work worth a damn with an iPad. -Noel
Even if you Sign out?
Robert Aldwinckle
---That wasn't really the issue. Yes, it was relatively slow to get to the bottom of long threads when logged-in, and yes, it was better when logged-out.
But the real issue was that the message editor just comes up in HTML mode. At least it's gotten to where one can actually log in and type a message, but there's no easy way to format it, save for inserting <br/> elements, etc. I can do that, but who wants to? The < and > characters on the iPad are not easy to reach either - probably on purpose. I got a Bluetooth Apple keyboard, which helped, but then the screen is just so tiny.
I was away for more than a week, having to rely on my iPad to keep me connected with the high tech world, and a lot of capability I enjoy on my multi-monitor workstation was just more difficult, if only barely available. It really just goes to underscore that a tablet really isn't a viable way to do anything serious.
I'm encouraged to hear that Microsoft has acknowledged the problem described here, but I'm not holding my breath that they're likely to work it out. They work out so few things lately... Sigh.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsTuesday, April 1, 2014 4:15 PM -
"One more user" can reproduce the issue.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsTuesday, April 1, 2014 5:02 PM -
http://social.technet.microsoft.com/Forums/ie/en-US/f3f815f3-be62-487e-911c-ed6a7565cd3a/ies-slowness-with-long-threads-on-microsoft-forums#d21c2741-b7e8-491c-8f3c-4db018a690c3
real issue was that the message editor just comes up in HTML mode.
Is there a NOT missing in that sentence? I am seeing that when I open threads in the Message list, e.g. reply to a Preview. A workaround is to type in Plain text, then Submit, then Edit. So far, the Edit always comes up with the toolbar. You will have to use the HTML button to add your own blockquote tags. Alternatively, try opening the thread in its own tab and see if you can Reply with Quote any better that way.
This is a recent defect. E.g. I only started seeing it since yesterday.
Robert Aldwinckle
---Edit: I think I see what you mean now. I didn't think of trying that. So what we're really seeing is an HTML source mode.
Edit: Reporting defect (and finding another)
- Edited by Robert Aldwinckle on forumsEditor Tuesday, April 1, 2014 6:31 PM Link to defect report
Tuesday, April 1, 2014 5:49 PMAnswerer -
"One more user" can reproduce the issue.
Robert Aldwinckle
---Tuesday, April 1, 2014 5:53 PMAnswerer -
>real issue was that the message editor just comes up in HTML mode.
Is there a NOT missing in that sentence?
Normally, from my PC workstation running IE11, I can just hit the Reply or Quote link, edit out what I don't want, then type what I want to type, using simple Return keystrokes to separate paragraphs.
I've done that here. I do have to enter the HTML editor to do things like add special formatting or tables, but generally speaking one need only normally just type sentences separated by carriage returns to get basic text to show. If you look up a few posts you see the result of my having tried that on the iPad - everything's just run together, including "-Noel", which was entered with a few extra carriage returns before it.
I screen-grabbed this post just before attaching the image and hitting the Submit button...
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsTuesday, April 1, 2014 8:24 PM -
Here's another thread with 373 replies that takes an age to load in IE:
The ones about what's wrong with the UI of Microsoft products tend to get very long, because everyone has an opinion, usually a strong one. In this case it's about the Antarctic desert that is the UI of Office 365/2013.
-Noel
Detailed how-to in my eBooks:
Configure The Windows 7 "To Work" Options
Configure The Windows 8 "To Work" OptionsTuesday, April 1, 2014 8:55 PM