Discussion:
FTLOG, I beg you to please fix this daily source of IE hell!
(too old to reply)
a.k.a.
2008-12-28 06:08:00 UTC
Permalink
Hi IE Team and MVPs -- I know you have your hands full, but I haven't seen
this mentioned so far, and I am really going to lose it if this hasn't been
fixed by the release of IE8....

You want to save a webpage to HDD, in MS' proprietary default (.MHT) file
format.

You watch as the "Save Webpage" dialogue box appears. The green bar
gradually creeps along toward 100%.

You hold your breath.

But it stalls out as the page begins to load -- anywhere from 12% to 99%.

You press cancel. Nothing happens. (Nothing EVER happens when you press
cancel if you don't catch the save dialogue within the first nanosecond that
it appears.)

You click the close X. Nothing happens. (Nothing EVER happens.)

You launch a second instance of IE.

You hold your breath.

If you're very lucky, the "Save Webpage" dialogue has now vanished from the
first instance of IE.

Otherwise, you're hosed. ALL of your open tabs are dead because your browser
went straight over the handlebars on colliding with one tiny hang in
downloading one miniscule web component -- a problem that IE has absolutely
no trouble handling when it's just DISPLAYING a page rather than saving it!

Is this a simple bug in the Save Webpage dialogue box?

Is this because IE doesn't bother to quarantine Tabs from each other?

Is this because IE does not bother to cache a page before it actually starts
writing the downloaded file to the proper directory?

Whatever it is, I wager this is the #1 IE bug at which users are hurling
epithets on a regular basis.

Please fix it -- and if you aren't going to, please EXPLAIN what the problem
is here. It's ABSOLUTELY INTOLERABLE.
All you

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=952ad09b-03dc-4172-b330-990c09fd0844&dg=microsoft.public.internetexplorer.beta
rob^_^
2008-12-28 18:56:25 UTC
Permalink
Hi aka.

Please always state your OS version and service pack level and whether the
problem is reproducible in no-Addons mode.

Regards.
Post by a.k.a.
Hi IE Team and MVPs -- I know you have your hands full, but I haven't seen
this mentioned so far, and I am really going to lose it if this hasn't been
fixed by the release of IE8....
You want to save a webpage to HDD, in MS' proprietary default (.MHT) file
format.
You watch as the "Save Webpage" dialogue box appears. The green bar
gradually creeps along toward 100%.
You hold your breath.
But it stalls out as the page begins to load -- anywhere from 12% to 99%.
You press cancel. Nothing happens. (Nothing EVER happens when you press
cancel if you don't catch the save dialogue within the first nanosecond that
it appears.)
You click the close X. Nothing happens. (Nothing EVER happens.)
You launch a second instance of IE.
You hold your breath.
If you're very lucky, the "Save Webpage" dialogue has now vanished from the
first instance of IE.
Otherwise, you're hosed. ALL of your open tabs are dead because your browser
went straight over the handlebars on colliding with one tiny hang in
downloading one miniscule web component -- a problem that IE has absolutely
no trouble handling when it's just DISPLAYING a page rather than saving it!
Is this a simple bug in the Save Webpage dialogue box?
Is this because IE doesn't bother to quarantine Tabs from each other?
Is this because IE does not bother to cache a page before it actually starts
writing the downloaded file to the proper directory?
Whatever it is, I wager this is the #1 IE bug at which users are hurling
epithets on a regular basis.
Please fix it -- and if you aren't going to, please EXPLAIN what the problem
is here. It's ABSOLUTELY INTOLERABLE.
All you
----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=952ad09b-03dc-4172-b330-990c09fd0844&dg=microsoft.public.internetexplorer.beta
a.k.a.
2008-12-30 02:04:01 UTC
Permalink
Hello, Rob,

Thanks for responding. The details you asked for are below. But the crucial
point is that this is a KNOWN bug seen by many IE7 users (and it's subtle
enough that I believe it's experienced by far more users than the small
percent of power users who report it). That's why I'm raising it here -- I
haven't seen anyone mention it in regards to fixing it for IE8 so far, and
this browser behavior drives me absolutely bananas when it kills off every
open tab you're using, so it's definitely time to raise this with the dev
team! Please don't hear this as a criticism in any way, Rob: What is worth
noting here is that if you haven't heard about this before, it indicates
there hasn't been a fix yet.

Let me point you to two threads in the IE7 forums that acknowledge this as a
longstanding problem -- from early 2007 versions through December of 2008!
(Make sure to at least read Lloyd GM's response on the first thread for a
good overview.)

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=f72b4bd5-38e3-468f-828d-5490ba20df52&sloc=en-us

http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=475cb50c-4dca-408f-bfec-024ae0f32958&sloc=en-us

I am running Vista x64, and IE build 7.0.6001.18000, but other people are
reporting it on XP as well -- as late as December '08. (I remember this
happening to me in IE8 as well, but I was so scared away by the crash rate in
IE8 that I'm waiting until IE8b3 to reinstall it.)

Is this reproducible in 'no-add-on mode'? No, but not for the reason you
expect. The problem is that this is always random, because it is obviously
brought on by server-side timeouts, which are by nature erratic and
non-reproducible even under fixed client-side conditions. What people are
reporting is this:
1. The user Saves the webpage in MHT format.
2. The webpage being saved has a 'no caching' request in the code.
3. There's a timeout on the server side.

Under those specific conditions, IE7+ always keels over dead. Somehow, the
Save Webpage dialogue box at that stage becomes non-responsive to any
command.

Other people have suggested that the Phishing Filter is implicated as well.
Someone else wants to also implicate a registry entry for download locations.
(It's all in those two past threads.)

The fact is that Opera never fails an MHT save like this. IE7+ does.

None of us have any idea why it's not universally reproducible, but I
believe there are a lot of users out there with this problem. Partly there's
under-reporting because it just seems to come with the territory of a
molasses-slow save rate for many MHT files. (99% and holding.... Cross your
fingers!) So in my case, for instance, it didn't even occur to me to revive
this as a known bug until just now. I'd just assumed it was widely understood
that IE was buggy to the point of crashing on MHT saves.

There's no reason that IE should force us to kill it when a save stalls out.
Surely that can be added to the list of required fixes for beta 3!

Thanks!
Post by rob^_^
Hi aka.
Please always state your OS version and service pack level and whether the
problem is reproducible in no-Addons mode.
Regards.
Post by a.k.a.
Hi IE Team and MVPs -- I know you have your hands full, but I haven't seen
this mentioned so far, and I am really going to lose it if this hasn't been
fixed by the release of IE8....
You want to save a webpage to HDD, in MS' proprietary default (.MHT) file
format.
You watch as the "Save Webpage" dialogue box appears. The green bar
gradually creeps along toward 100%.
You hold your breath.
But it stalls out as the page begins to load -- anywhere from 12% to 99%.
You press cancel. Nothing happens. (Nothing EVER happens when you press
cancel if you don't catch the save dialogue within the first nanosecond that
it appears.)
You click the close X. Nothing happens. (Nothing EVER happens.)
You launch a second instance of IE.
You hold your breath.
If you're very lucky, the "Save Webpage" dialogue has now vanished from the
first instance of IE.
Otherwise, you're hosed. ALL of your open tabs are dead because your browser
went straight over the handlebars on colliding with one tiny hang in
downloading one miniscule web component -- a problem that IE has absolutely
no trouble handling when it's just DISPLAYING a page rather than saving it!
Is this a simple bug in the Save Webpage dialogue box?
Is this because IE doesn't bother to quarantine Tabs from each other?
Is this because IE does not bother to cache a page before it actually starts
writing the downloaded file to the proper directory?
Whatever it is, I wager this is the #1 IE bug at which users are hurling
epithets on a regular basis.
Please fix it -- and if you aren't going to, please EXPLAIN what the problem
is here. It's ABSOLUTELY INTOLERABLE.
All you
----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=952ad09b-03dc-4172-b330-990c09fd0844&dg=microsoft.public.internetexplorer.beta
a.k.a.
2009-01-01 01:58:00 UTC
Permalink
Rob,

I can give you more details about this bug: Probably not in every case, but
at least more often than not, the hangs have occurred at the part of the MHT
save where a "web analytics" firm is making a cookie request. The MHT save
dialogue often hangs at points like this:

Saving: http://c25.statcounter.com/[garbage numbers]

Of course, the site I'm trying to save has nothing whatsoever to do with
statcounter.com. In this case it was this site:

www.uwec.edu/HELP/Office07/hiddendata.htm

Today, it hung on statcounter.com. The last time I captured a OneNote
screenshot, it was hanging on webtrends.com

Yes, the phishing filter is on. I do have the browser set to "block" third
party cookies. I'm also running "prompt" for all cookies. But neither of
those websites was on my blocked sites list.

Users should not have to allow all 3rd party cookies just to stop IE from
crashing over this. It ought to be the other way around, if the IE Team
honestly wants to protect user security. That is, if it's third party cookies
during an MHT save that are crashing IE, then there needs to be a safety
valve put in to stop that from occurring.

Thanks for your attention.
Post by a.k.a.
Hello, Rob,
Thanks for responding. The details you asked for are below. But the crucial
point is that this is a KNOWN bug seen by many IE7 users (and it's subtle
enough that I believe it's experienced by far more users than the small
percent of power users who report it). That's why I'm raising it here -- I
haven't seen anyone mention it in regards to fixing it for IE8 so far, and
this browser behavior drives me absolutely bananas when it kills off every
open tab you're using, so it's definitely time to raise this with the dev
team! Please don't hear this as a criticism in any way, Rob: What is worth
noting here is that if you haven't heard about this before, it indicates
there hasn't been a fix yet.
Let me point you to two threads in the IE7 forums that acknowledge this as a
longstanding problem -- from early 2007 versions through December of 2008!
(Make sure to at least read Lloyd GM's response on the first thread for a
good overview.)
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=f72b4bd5-38e3-468f-828d-5490ba20df52&sloc=en-us
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=475cb50c-4dca-408f-bfec-024ae0f32958&sloc=en-us
I am running Vista x64, and IE build 7.0.6001.18000, but other people are
reporting it on XP as well -- as late as December '08. (I remember this
happening to me in IE8 as well, but I was so scared away by the crash rate in
IE8 that I'm waiting until IE8b3 to reinstall it.)
Is this reproducible in 'no-add-on mode'? No, but not for the reason you
expect. The problem is that this is always random, because it is obviously
brought on by server-side timeouts, which are by nature erratic and
non-reproducible even under fixed client-side conditions. What people are
1. The user Saves the webpage in MHT format.
2. The webpage being saved has a 'no caching' request in the code.
3. There's a timeout on the server side.
Under those specific conditions, IE7+ always keels over dead. Somehow, the
Save Webpage dialogue box at that stage becomes non-responsive to any
command.
Other people have suggested that the Phishing Filter is implicated as well.
Someone else wants to also implicate a registry entry for download locations.
(It's all in those two past threads.)
The fact is that Opera never fails an MHT save like this. IE7+ does.
None of us have any idea why it's not universally reproducible, but I
believe there are a lot of users out there with this problem. Partly there's
under-reporting because it just seems to come with the territory of a
molasses-slow save rate for many MHT files. (99% and holding.... Cross your
fingers!) So in my case, for instance, it didn't even occur to me to revive
this as a known bug until just now. I'd just assumed it was widely understood
that IE was buggy to the point of crashing on MHT saves.
There's no reason that IE should force us to kill it when a save stalls out.
Surely that can be added to the list of required fixes for beta 3!
Thanks!
Post by rob^_^
Hi aka.
Please always state your OS version and service pack level and whether the
problem is reproducible in no-Addons mode.
Regards.
Post by a.k.a.
Hi IE Team and MVPs -- I know you have your hands full, but I haven't seen
this mentioned so far, and I am really going to lose it if this hasn't been
fixed by the release of IE8....
You want to save a webpage to HDD, in MS' proprietary default (.MHT) file
format.
You watch as the "Save Webpage" dialogue box appears. The green bar
gradually creeps along toward 100%.
You hold your breath.
But it stalls out as the page begins to load -- anywhere from 12% to 99%.
You press cancel. Nothing happens. (Nothing EVER happens when you press
cancel if you don't catch the save dialogue within the first nanosecond that
it appears.)
You click the close X. Nothing happens. (Nothing EVER happens.)
You launch a second instance of IE.
You hold your breath.
If you're very lucky, the "Save Webpage" dialogue has now vanished from the
first instance of IE.
Otherwise, you're hosed. ALL of your open tabs are dead because your browser
went straight over the handlebars on colliding with one tiny hang in
downloading one miniscule web component -- a problem that IE has absolutely
no trouble handling when it's just DISPLAYING a page rather than saving it!
Is this a simple bug in the Save Webpage dialogue box?
Is this because IE doesn't bother to quarantine Tabs from each other?
Is this because IE does not bother to cache a page before it actually starts
writing the downloaded file to the proper directory?
Whatever it is, I wager this is the #1 IE bug at which users are hurling
epithets on a regular basis.
Please fix it -- and if you aren't going to, please EXPLAIN what the problem
is here. It's ABSOLUTELY INTOLERABLE.
All you
----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=952ad09b-03dc-4172-b330-990c09fd0844&dg=microsoft.public.internetexplorer.beta
a.k.a.
2009-01-01 22:52:01 UTC
Permalink
Rob,

Another case where IE7 just hung is on a GIF-rich page. This was a .EDU
site, so nothing pernicious. IE either failed to send the proper command to
the server, the request packet was lost in transit, or the server failed to
send the information. (The server has not been slow to respond on other
occasions, so it is more likely one of the first two.)

There was no 3rd party cookie involved.

In this particular instance, clicking the Cancel and Red X buttons (over and
over) did absolutely nothing. IE had definitely hung.

But as I noted in my first post, launching a second instance of IE "over"
the first one made the Save Webpage box disappear.

This is the site. I doubt you'll be able to get it to reproduce the hang,
but you never know:
http://www.ats.ucla.edu/stat/r/modules/exploring_w_graphics.htm
Post by a.k.a.
Hello, Rob,
Thanks for responding. The details you asked for are below. But the crucial
point is that this is a KNOWN bug seen by many IE7 users (and it's subtle
enough that I believe it's experienced by far more users than the small
percent of power users who report it). That's why I'm raising it here -- I
haven't seen anyone mention it in regards to fixing it for IE8 so far, and
this browser behavior drives me absolutely bananas when it kills off every
open tab you're using, so it's definitely time to raise this with the dev
team! Please don't hear this as a criticism in any way, Rob: What is worth
noting here is that if you haven't heard about this before, it indicates
there hasn't been a fix yet.
Let me point you to two threads in the IE7 forums that acknowledge this as a
longstanding problem -- from early 2007 versions through December of 2008!
(Make sure to at least read Lloyd GM's response on the first thread for a
good overview.)
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=f72b4bd5-38e3-468f-828d-5490ba20df52&sloc=en-us
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=475cb50c-4dca-408f-bfec-024ae0f32958&sloc=en-us
I am running Vista x64, and IE build 7.0.6001.18000, but other people are
reporting it on XP as well -- as late as December '08. (I remember this
happening to me in IE8 as well, but I was so scared away by the crash rate in
IE8 that I'm waiting until IE8b3 to reinstall it.)
Is this reproducible in 'no-add-on mode'? No, but not for the reason you
expect. The problem is that this is always random, because it is obviously
brought on by server-side timeouts, which are by nature erratic and
non-reproducible even under fixed client-side conditions. What people are
1. The user Saves the webpage in MHT format.
2. The webpage being saved has a 'no caching' request in the code.
3. There's a timeout on the server side.
Under those specific conditions, IE7+ always keels over dead. Somehow, the
Save Webpage dialogue box at that stage becomes non-responsive to any
command.
Other people have suggested that the Phishing Filter is implicated as well.
Someone else wants to also implicate a registry entry for download locations.
(It's all in those two past threads.)
The fact is that Opera never fails an MHT save like this. IE7+ does.
None of us have any idea why it's not universally reproducible, but I
believe there are a lot of users out there with this problem. Partly there's
under-reporting because it just seems to come with the territory of a
molasses-slow save rate for many MHT files. (99% and holding.... Cross your
fingers!) So in my case, for instance, it didn't even occur to me to revive
this as a known bug until just now. I'd just assumed it was widely understood
that IE was buggy to the point of crashing on MHT saves.
There's no reason that IE should force us to kill it when a save stalls out.
Surely that can be added to the list of required fixes for beta 3!
Thanks!
Post by rob^_^
Hi aka.
Please always state your OS version and service pack level and whether the
problem is reproducible in no-Addons mode.
Regards.
Post by a.k.a.
Hi IE Team and MVPs -- I know you have your hands full, but I haven't seen
this mentioned so far, and I am really going to lose it if this hasn't been
fixed by the release of IE8....
You want to save a webpage to HDD, in MS' proprietary default (.MHT) file
format.
You watch as the "Save Webpage" dialogue box appears. The green bar
gradually creeps along toward 100%.
You hold your breath.
But it stalls out as the page begins to load -- anywhere from 12% to 99%.
You press cancel. Nothing happens. (Nothing EVER happens when you press
cancel if you don't catch the save dialogue within the first nanosecond that
it appears.)
You click the close X. Nothing happens. (Nothing EVER happens.)
You launch a second instance of IE.
You hold your breath.
If you're very lucky, the "Save Webpage" dialogue has now vanished from the
first instance of IE.
Otherwise, you're hosed. ALL of your open tabs are dead because your browser
went straight over the handlebars on colliding with one tiny hang in
downloading one miniscule web component -- a problem that IE has absolutely
no trouble handling when it's just DISPLAYING a page rather than saving it!
Is this a simple bug in the Save Webpage dialogue box?
Is this because IE doesn't bother to quarantine Tabs from each other?
Is this because IE does not bother to cache a page before it actually starts
writing the downloaded file to the proper directory?
Whatever it is, I wager this is the #1 IE bug at which users are hurling
epithets on a regular basis.
Please fix it -- and if you aren't going to, please EXPLAIN what the problem
is here. It's ABSOLUTELY INTOLERABLE.
All you
----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=952ad09b-03dc-4172-b330-990c09fd0844&dg=microsoft.public.internetexplorer.beta
Joe
2009-01-12 15:35:02 UTC
Permalink
I have had this happen on XP x86 with IE7, on Vista x86 with IE7 and IE8, and
on Windows 7 with IE8. Doesn't really matter what security mode the browser
is in, and the problem becomes moe frequent on slow internet connections.

Please fix it and stop IE8 becoming another joke.
Post by a.k.a.
Rob,
Another case where IE7 just hung is on a GIF-rich page. This was a .EDU
site, so nothing pernicious. IE either failed to send the proper command to
the server, the request packet was lost in transit, or the server failed to
send the information. (The server has not been slow to respond on other
occasions, so it is more likely one of the first two.)
There was no 3rd party cookie involved.
In this particular instance, clicking the Cancel and Red X buttons (over and
over) did absolutely nothing. IE had definitely hung.
But as I noted in my first post, launching a second instance of IE "over"
the first one made the Save Webpage box disappear.
This is the site. I doubt you'll be able to get it to reproduce the hang,
http://www.ats.ucla.edu/stat/r/modules/exploring_w_graphics.htm
Post by a.k.a.
Hello, Rob,
Thanks for responding. The details you asked for are below. But the crucial
point is that this is a KNOWN bug seen by many IE7 users (and it's subtle
enough that I believe it's experienced by far more users than the small
percent of power users who report it). That's why I'm raising it here -- I
haven't seen anyone mention it in regards to fixing it for IE8 so far, and
this browser behavior drives me absolutely bananas when it kills off every
open tab you're using, so it's definitely time to raise this with the dev
team! Please don't hear this as a criticism in any way, Rob: What is worth
noting here is that if you haven't heard about this before, it indicates
there hasn't been a fix yet.
Let me point you to two threads in the IE7 forums that acknowledge this as a
longstanding problem -- from early 2007 versions through December of 2008!
(Make sure to at least read Lloyd GM's response on the first thread for a
good overview.)
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=f72b4bd5-38e3-468f-828d-5490ba20df52&sloc=en-us
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=475cb50c-4dca-408f-bfec-024ae0f32958&sloc=en-us
I am running Vista x64, and IE build 7.0.6001.18000, but other people are
reporting it on XP as well -- as late as December '08. (I remember this
happening to me in IE8 as well, but I was so scared away by the crash rate in
IE8 that I'm waiting until IE8b3 to reinstall it.)
Is this reproducible in 'no-add-on mode'? No, but not for the reason you
expect. The problem is that this is always random, because it is obviously
brought on by server-side timeouts, which are by nature erratic and
non-reproducible even under fixed client-side conditions. What people are
1. The user Saves the webpage in MHT format.
2. The webpage being saved has a 'no caching' request in the code.
3. There's a timeout on the server side.
Under those specific conditions, IE7+ always keels over dead. Somehow, the
Save Webpage dialogue box at that stage becomes non-responsive to any
command.
Other people have suggested that the Phishing Filter is implicated as well.
Someone else wants to also implicate a registry entry for download locations.
(It's all in those two past threads.)
The fact is that Opera never fails an MHT save like this. IE7+ does.
None of us have any idea why it's not universally reproducible, but I
believe there are a lot of users out there with this problem. Partly there's
under-reporting because it just seems to come with the territory of a
molasses-slow save rate for many MHT files. (99% and holding.... Cross your
fingers!) So in my case, for instance, it didn't even occur to me to revive
this as a known bug until just now. I'd just assumed it was widely understood
that IE was buggy to the point of crashing on MHT saves.
There's no reason that IE should force us to kill it when a save stalls out.
Surely that can be added to the list of required fixes for beta 3!
Thanks!
Post by rob^_^
Hi aka.
Please always state your OS version and service pack level and whether the
problem is reproducible in no-Addons mode.
Regards.
Post by a.k.a.
Hi IE Team and MVPs -- I know you have your hands full, but I haven't seen
this mentioned so far, and I am really going to lose it if this hasn't been
fixed by the release of IE8....
You want to save a webpage to HDD, in MS' proprietary default (.MHT) file
format.
You watch as the "Save Webpage" dialogue box appears. The green bar
gradually creeps along toward 100%.
You hold your breath.
But it stalls out as the page begins to load -- anywhere from 12% to 99%.
You press cancel. Nothing happens. (Nothing EVER happens when you press
cancel if you don't catch the save dialogue within the first nanosecond that
it appears.)
You click the close X. Nothing happens. (Nothing EVER happens.)
You launch a second instance of IE.
You hold your breath.
If you're very lucky, the "Save Webpage" dialogue has now vanished from the
first instance of IE.
Otherwise, you're hosed. ALL of your open tabs are dead because your browser
went straight over the handlebars on colliding with one tiny hang in
downloading one miniscule web component -- a problem that IE has absolutely
no trouble handling when it's just DISPLAYING a page rather than saving it!
Is this a simple bug in the Save Webpage dialogue box?
Is this because IE doesn't bother to quarantine Tabs from each other?
Is this because IE does not bother to cache a page before it actually starts
writing the downloaded file to the proper directory?
Whatever it is, I wager this is the #1 IE bug at which users are hurling
epithets on a regular basis.
Please fix it -- and if you aren't going to, please EXPLAIN what the problem
is here. It's ABSOLUTELY INTOLERABLE.
All you
----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=952ad09b-03dc-4172-b330-990c09fd0844&dg=microsoft.public.internetexplorer.beta
a.k.a.
2009-01-12 21:02:01 UTC
Permalink
Joe, I can concurr with the slower internet connections -- WiFi in my case.
IE just waits interminably, and unresponsively, for packets it won't get, and
I don't get why the Save dialogue can't break it.

Just wondering, Joe, are you running IE in Administrator accounts in Vista?
I'm asking because I don't think it's exclusive to Admin, but I think it's
more replicable in Admin.

I've noticed that IE prioritizes cookies differently between Admin and
normal users. In Admin accounts or settings, the cookies from other tabs
don't pop up on your current tab view. They just silently blink orange, and
this can crash IE too, because there are occasions when the cookie request
box never materializes. The GUI works fine, but the browser engine crashes,
and you have to restart to reconnect.

My experience with the UCLA site hang below could have been a similar
situation. Sitecounter wanted to send a cookie, and the Save Webpage process
had better things to do than respond to that request, so the save hung on it.

I do think this Save Webpage crash happens in non-Admin mode as IE bogs down
in a session. But at least in non-Admin mode, the cookie requests from other
tabs show up on your current tab, and are more likely to all get handled
appropriately.

THANK YOU for adding to this thread! It's important to get eyewitness
corroboration. Can you do me a favor and mark all of the posts in this thread
as "Useful." Only when the count goes up does this get passed along. Also,
did you see the threads in the IE7 forum and mark them useful?

This bug submission process is also a bit buggy.

a.k.a.
Post by Joe
I have had this happen on XP x86 with IE7, on Vista x86 with IE7 and IE8, and
on Windows 7 with IE8. Doesn't really matter what security mode the browser
is in, and the problem becomes moe frequent on slow internet connections.
Please fix it and stop IE8 becoming another joke.
Post by a.k.a.
Rob,
Another case where IE7 just hung is on a GIF-rich page. This was a .EDU
site, so nothing pernicious. IE either failed to send the proper command to
the server, the request packet was lost in transit, or the server failed to
send the information. (The server has not been slow to respond on other
occasions, so it is more likely one of the first two.)
There was no 3rd party cookie involved.
In this particular instance, clicking the Cancel and Red X buttons (over and
over) did absolutely nothing. IE had definitely hung.
But as I noted in my first post, launching a second instance of IE "over"
the first one made the Save Webpage box disappear.
This is the site. I doubt you'll be able to get it to reproduce the hang,
http://www.ats.ucla.edu/stat/r/modules/exploring_w_graphics.htm
Post by a.k.a.
Hello, Rob,
Thanks for responding. The details you asked for are below. But the crucial
point is that this is a KNOWN bug seen by many IE7 users (and it's subtle
enough that I believe it's experienced by far more users than the small
percent of power users who report it). That's why I'm raising it here -- I
haven't seen anyone mention it in regards to fixing it for IE8 so far, and
this browser behavior drives me absolutely bananas when it kills off every
open tab you're using, so it's definitely time to raise this with the dev
team! Please don't hear this as a criticism in any way, Rob: What is worth
noting here is that if you haven't heard about this before, it indicates
there hasn't been a fix yet.
Let me point you to two threads in the IE7 forums that acknowledge this as a
longstanding problem -- from early 2007 versions through December of 2008!
(Make sure to at least read Lloyd GM's response on the first thread for a
good overview.)
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=f72b4bd5-38e3-468f-828d-5490ba20df52&sloc=en-us
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=475cb50c-4dca-408f-bfec-024ae0f32958&sloc=en-us
I am running Vista x64, and IE build 7.0.6001.18000, but other people are
reporting it on XP as well -- as late as December '08. (I remember this
happening to me in IE8 as well, but I was so scared away by the crash rate in
IE8 that I'm waiting until IE8b3 to reinstall it.)
Is this reproducible in 'no-add-on mode'? No, but not for the reason you
expect. The problem is that this is always random, because it is obviously
brought on by server-side timeouts, which are by nature erratic and
non-reproducible even under fixed client-side conditions. What people are
1. The user Saves the webpage in MHT format.
2. The webpage being saved has a 'no caching' request in the code.
3. There's a timeout on the server side.
Under those specific conditions, IE7+ always keels over dead. Somehow, the
Save Webpage dialogue box at that stage becomes non-responsive to any
command.
Other people have suggested that the Phishing Filter is implicated as well.
Someone else wants to also implicate a registry entry for download locations.
(It's all in those two past threads.)
The fact is that Opera never fails an MHT save like this. IE7+ does.
None of us have any idea why it's not universally reproducible, but I
believe there are a lot of users out there with this problem. Partly there's
under-reporting because it just seems to come with the territory of a
molasses-slow save rate for many MHT files. (99% and holding.... Cross your
fingers!) So in my case, for instance, it didn't even occur to me to revive
this as a known bug until just now. I'd just assumed it was widely understood
that IE was buggy to the point of crashing on MHT saves.
There's no reason that IE should force us to kill it when a save stalls out.
Surely that can be added to the list of required fixes for beta 3!
Thanks!
Post by rob^_^
Hi aka.
Please always state your OS version and service pack level and whether the
problem is reproducible in no-Addons mode.
Regards.
Post by a.k.a.
Hi IE Team and MVPs -- I know you have your hands full, but I haven't seen
this mentioned so far, and I am really going to lose it if this hasn't been
fixed by the release of IE8....
You want to save a webpage to HDD, in MS' proprietary default (.MHT) file
format.
You watch as the "Save Webpage" dialogue box appears. The green bar
gradually creeps along toward 100%.
You hold your breath.
But it stalls out as the page begins to load -- anywhere from 12% to 99%.
You press cancel. Nothing happens. (Nothing EVER happens when you press
cancel if you don't catch the save dialogue within the first nanosecond
that
it appears.)
You click the close X. Nothing happens. (Nothing EVER happens.)
You launch a second instance of IE.
You hold your breath.
If you're very lucky, the "Save Webpage" dialogue has now vanished from the
first instance of IE.
Otherwise, you're hosed. ALL of your open tabs are dead because your
browser
went straight over the handlebars on colliding with one tiny hang in
downloading one miniscule web component -- a problem that IE has absolutely
no trouble handling when it's just DISPLAYING a page rather than saving it!
Is this a simple bug in the Save Webpage dialogue box?
Is this because IE doesn't bother to quarantine Tabs from each other?
Is this because IE does not bother to cache a page before it actually
starts
writing the downloaded file to the proper directory?
Whatever it is, I wager this is the #1 IE bug at which users are hurling
epithets on a regular basis.
Please fix it -- and if you aren't going to, please EXPLAIN what the
problem
is here. It's ABSOLUTELY INTOLERABLE.
All you
----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow
this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=952ad09b-03dc-4172-b330-990c09fd0844&dg=microsoft.public.internetexplorer.beta
The Shadow
2009-01-14 21:16:06 UTC
Permalink
Hey, sorry I took so long. I solved my problem, so I took my sweet old time
getting to my previous post.
In my case it was my ZoneAlarm firewall that was causing the prolem. I got
fed up with it, uninstalled it, used Windows firewall with Avast Antivirus,
and have happy ever since. It also cut my boot time by about a quarter.
Try turning off your firewall, and use Windows Defender. If that does not
work uninstall your firewall, and at least temporarily stick with the Windows
firewall. In my instance, even turning off ZoneAlarm did not fix the problem.
As such, I do not know what ZoneAlarm was doing, but it was causing an
annoying problem even after turning it off.
Hope this helps. :)
Post by a.k.a.
Joe, I can concurr with the slower internet connections -- WiFi in my case.
IE just waits interminably, and unresponsively, for packets it won't get, and
I don't get why the Save dialogue can't break it.
Just wondering, Joe, are you running IE in Administrator accounts in Vista?
I'm asking because I don't think it's exclusive to Admin, but I think it's
more replicable in Admin.
I've noticed that IE prioritizes cookies differently between Admin and
normal users. In Admin accounts or settings, the cookies from other tabs
don't pop up on your current tab view. They just silently blink orange, and
this can crash IE too, because there are occasions when the cookie request
box never materializes. The GUI works fine, but the browser engine crashes,
and you have to restart to reconnect.
My experience with the UCLA site hang below could have been a similar
situation. Sitecounter wanted to send a cookie, and the Save Webpage process
had better things to do than respond to that request, so the save hung on it.
I do think this Save Webpage crash happens in non-Admin mode as IE bogs down
in a session. But at least in non-Admin mode, the cookie requests from other
tabs show up on your current tab, and are more likely to all get handled
appropriately.
THANK YOU for adding to this thread! It's important to get eyewitness
corroboration. Can you do me a favor and mark all of the posts in this thread
as "Useful." Only when the count goes up does this get passed along. Also,
did you see the threads in the IE7 forum and mark them useful?
This bug submission process is also a bit buggy.
a.k.a.
Post by Joe
I have had this happen on XP x86 with IE7, on Vista x86 with IE7 and IE8, and
on Windows 7 with IE8. Doesn't really matter what security mode the browser
is in, and the problem becomes moe frequent on slow internet connections.
Please fix it and stop IE8 becoming another joke.
Post by a.k.a.
Rob,
Another case where IE7 just hung is on a GIF-rich page. This was a .EDU
site, so nothing pernicious. IE either failed to send the proper command to
the server, the request packet was lost in transit, or the server failed to
send the information. (The server has not been slow to respond on other
occasions, so it is more likely one of the first two.)
There was no 3rd party cookie involved.
In this particular instance, clicking the Cancel and Red X buttons (over and
over) did absolutely nothing. IE had definitely hung.
But as I noted in my first post, launching a second instance of IE "over"
the first one made the Save Webpage box disappear.
This is the site. I doubt you'll be able to get it to reproduce the hang,
http://www.ats.ucla.edu/stat/r/modules/exploring_w_graphics.htm
Post by a.k.a.
Hello, Rob,
Thanks for responding. The details you asked for are below. But the crucial
point is that this is a KNOWN bug seen by many IE7 users (and it's subtle
enough that I believe it's experienced by far more users than the small
percent of power users who report it). That's why I'm raising it here -- I
haven't seen anyone mention it in regards to fixing it for IE8 so far, and
this browser behavior drives me absolutely bananas when it kills off every
open tab you're using, so it's definitely time to raise this with the dev
team! Please don't hear this as a criticism in any way, Rob: What is worth
noting here is that if you haven't heard about this before, it indicates
there hasn't been a fix yet.
Let me point you to two threads in the IE7 forums that acknowledge this as a
longstanding problem -- from early 2007 versions through December of 2008!
(Make sure to at least read Lloyd GM's response on the first thread for a
good overview.)
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=f72b4bd5-38e3-468f-828d-5490ba20df52&sloc=en-us
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=475cb50c-4dca-408f-bfec-024ae0f32958&sloc=en-us
I am running Vista x64, and IE build 7.0.6001.18000, but other people are
reporting it on XP as well -- as late as December '08. (I remember this
happening to me in IE8 as well, but I was so scared away by the crash rate in
IE8 that I'm waiting until IE8b3 to reinstall it.)
Is this reproducible in 'no-add-on mode'? No, but not for the reason you
expect. The problem is that this is always random, because it is obviously
brought on by server-side timeouts, which are by nature erratic and
non-reproducible even under fixed client-side conditions. What people are
1. The user Saves the webpage in MHT format.
2. The webpage being saved has a 'no caching' request in the code.
3. There's a timeout on the server side.
Under those specific conditions, IE7+ always keels over dead. Somehow, the
Save Webpage dialogue box at that stage becomes non-responsive to any
command.
Other people have suggested that the Phishing Filter is implicated as well.
Someone else wants to also implicate a registry entry for download locations.
(It's all in those two past threads.)
The fact is that Opera never fails an MHT save like this. IE7+ does.
None of us have any idea why it's not universally reproducible, but I
believe there are a lot of users out there with this problem. Partly there's
under-reporting because it just seems to come with the territory of a
molasses-slow save rate for many MHT files. (99% and holding.... Cross your
fingers!) So in my case, for instance, it didn't even occur to me to revive
this as a known bug until just now. I'd just assumed it was widely understood
that IE was buggy to the point of crashing on MHT saves.
There's no reason that IE should force us to kill it when a save stalls out.
Surely that can be added to the list of required fixes for beta 3!
Thanks!
Post by rob^_^
Hi aka.
Please always state your OS version and service pack level and whether the
problem is reproducible in no-Addons mode.
Regards.
Post by a.k.a.
Hi IE Team and MVPs -- I know you have your hands full, but I haven't seen
this mentioned so far, and I am really going to lose it if this hasn't
been
fixed by the release of IE8....
You want to save a webpage to HDD, in MS' proprietary default (.MHT) file
format.
You watch as the "Save Webpage" dialogue box appears. The green bar
gradually creeps along toward 100%.
You hold your breath.
But it stalls out as the page begins to load -- anywhere from 12% to 99%.
You press cancel. Nothing happens. (Nothing EVER happens when you press
cancel if you don't catch the save dialogue within the first nanosecond
that
it appears.)
You click the close X. Nothing happens. (Nothing EVER happens.)
You launch a second instance of IE.
You hold your breath.
If you're very lucky, the "Save Webpage" dialogue has now vanished from
the
first instance of IE.
Otherwise, you're hosed. ALL of your open tabs are dead because your
browser
went straight over the handlebars on colliding with one tiny hang in
downloading one miniscule web component -- a problem that IE has
absolutely
no trouble handling when it's just DISPLAYING a page rather than saving
it!
Is this a simple bug in the Save Webpage dialogue box?
Is this because IE doesn't bother to quarantine Tabs from each other?
Is this because IE does not bother to cache a page before it actually
starts
writing the downloaded file to the proper directory?
Whatever it is, I wager this is the #1 IE bug at which users are hurling
epithets on a regular basis.
Please fix it -- and if you aren't going to, please EXPLAIN what the
problem
is here. It's ABSOLUTELY INTOLERABLE.
All you
----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow
this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=952ad09b-03dc-4172-b330-990c09fd0844&dg=microsoft.public.internetexplorer.beta
cyberyetti
2009-12-01 11:12:01 UTC
Permalink
getting this problem too. Not with txt or complete html saves though. Running
Vista Ultimate x64 SP2 with ie8 defender and windows firewall off as AVG 9
on. Not reproducible in Opera, Firefox, Safari or Chrome. Thinning hair
getting thinner by the day. BTW killiong just the appropriate thread with
process explorer (or task manager) restores ie8 to working condition but
doesn't save the page. Is there a good save as PDF about? that should clear
this up in a way.
Post by The Shadow
Hey, sorry I took so long. I solved my problem, so I took my sweet old time
getting to my previous post.
In my case it was my ZoneAlarm firewall that was causing the prolem. I got
fed up with it, uninstalled it, used Windows firewall with Avast Antivirus,
and have happy ever since. It also cut my boot time by about a quarter.
Try turning off your firewall, and use Windows Defender. If that does not
work uninstall your firewall, and at least temporarily stick with the Windows
firewall. In my instance, even turning off ZoneAlarm did not fix the problem.
As such, I do not know what ZoneAlarm was doing, but it was causing an
annoying problem even after turning it off.
Hope this helps. :)
Post by a.k.a.
Joe, I can concurr with the slower internet connections -- WiFi in my case.
IE just waits interminably, and unresponsively, for packets it won't get, and
I don't get why the Save dialogue can't break it.
Just wondering, Joe, are you running IE in Administrator accounts in Vista?
I'm asking because I don't think it's exclusive to Admin, but I think it's
more replicable in Admin.
I've noticed that IE prioritizes cookies differently between Admin and
normal users. In Admin accounts or settings, the cookies from other tabs
don't pop up on your current tab view. They just silently blink orange, and
this can crash IE too, because there are occasions when the cookie request
box never materializes. The GUI works fine, but the browser engine crashes,
and you have to restart to reconnect.
My experience with the UCLA site hang below could have been a similar
situation. Sitecounter wanted to send a cookie, and the Save Webpage process
had better things to do than respond to that request, so the save hung on it.
I do think this Save Webpage crash happens in non-Admin mode as IE bogs down
in a session. But at least in non-Admin mode, the cookie requests from other
tabs show up on your current tab, and are more likely to all get handled
appropriately.
THANK YOU for adding to this thread! It's important to get eyewitness
corroboration. Can you do me a favor and mark all of the posts in this thread
as "Useful." Only when the count goes up does this get passed along. Also,
did you see the threads in the IE7 forum and mark them useful?
This bug submission process is also a bit buggy.
a.k.a.
Post by Joe
I have had this happen on XP x86 with IE7, on Vista x86 with IE7 and IE8, and
on Windows 7 with IE8. Doesn't really matter what security mode the browser
is in, and the problem becomes moe frequent on slow internet connections.
Please fix it and stop IE8 becoming another joke.
Post by a.k.a.
Rob,
Another case where IE7 just hung is on a GIF-rich page. This was a .EDU
site, so nothing pernicious. IE either failed to send the proper command to
the server, the request packet was lost in transit, or the server failed to
send the information. (The server has not been slow to respond on other
occasions, so it is more likely one of the first two.)
There was no 3rd party cookie involved.
In this particular instance, clicking the Cancel and Red X buttons (over and
over) did absolutely nothing. IE had definitely hung.
But as I noted in my first post, launching a second instance of IE "over"
the first one made the Save Webpage box disappear.
This is the site. I doubt you'll be able to get it to reproduce the hang,
http://www.ats.ucla.edu/stat/r/modules/exploring_w_graphics.htm
Post by a.k.a.
Hello, Rob,
Thanks for responding. The details you asked for are below. But the crucial
point is that this is a KNOWN bug seen by many IE7 users (and it's subtle
enough that I believe it's experienced by far more users than the small
percent of power users who report it). That's why I'm raising it here -- I
haven't seen anyone mention it in regards to fixing it for IE8 so far, and
this browser behavior drives me absolutely bananas when it kills off every
open tab you're using, so it's definitely time to raise this with the dev
team! Please don't hear this as a criticism in any way, Rob: What is worth
noting here is that if you haven't heard about this before, it indicates
there hasn't been a fix yet.
Let me point you to two threads in the IE7 forums that acknowledge this as a
longstanding problem -- from early 2007 versions through December of 2008!
(Make sure to at least read Lloyd GM's response on the first thread for a
good overview.)
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=f72b4bd5-38e3-468f-828d-5490ba20df52&sloc=en-us
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=475cb50c-4dca-408f-bfec-024ae0f32958&sloc=en-us
I am running Vista x64, and IE build 7.0.6001.18000, but other people are
reporting it on XP as well -- as late as December '08. (I remember this
happening to me in IE8 as well, but I was so scared away by the crash rate in
IE8 that I'm waiting until IE8b3 to reinstall it.)
Is this reproducible in 'no-add-on mode'? No, but not for the reason you
expect. The problem is that this is always random, because it is obviously
brought on by server-side timeouts, which are by nature erratic and
non-reproducible even under fixed client-side conditions. What people are
1. The user Saves the webpage in MHT format.
2. The webpage being saved has a 'no caching' request in the code.
3. There's a timeout on the server side.
Under those specific conditions, IE7+ always keels over dead. Somehow, the
Save Webpage dialogue box at that stage becomes non-responsive to any
command.
Other people have suggested that the Phishing Filter is implicated as well.
Someone else wants to also implicate a registry entry for download locations.
(It's all in those two past threads.)
The fact is that Opera never fails an MHT save like this. IE7+ does.
None of us have any idea why it's not universally reproducible, but I
believe there are a lot of users out there with this problem. Partly there's
under-reporting because it just seems to come with the territory of a
molasses-slow save rate for many MHT files. (99% and holding.... Cross your
fingers!) So in my case, for instance, it didn't even occur to me to revive
this as a known bug until just now. I'd just assumed it was widely understood
that IE was buggy to the point of crashing on MHT saves.
There's no reason that IE should force us to kill it when a save stalls out.
Surely that can be added to the list of required fixes for beta 3!
Thanks!
Post by rob^_^
Hi aka.
Please always state your OS version and service pack level and whether the
problem is reproducible in no-Addons mode.
Regards.
Post by a.k.a.
Hi IE Team and MVPs -- I know you have your hands full, but I haven't seen
this mentioned so far, and I am really going to lose it if this hasn't
been
fixed by the release of IE8....
You want to save a webpage to HDD, in MS' proprietary default (.MHT) file
format.
You watch as the "Save Webpage" dialogue box appears. The green bar
gradually creeps along toward 100%.
You hold your breath.
But it stalls out as the page begins to load -- anywhere from 12% to 99%.
You press cancel. Nothing happens. (Nothing EVER happens when you press
cancel if you don't catch the save dialogue within the first nanosecond
that
it appears.)
You click the close X. Nothing happens. (Nothing EVER happens.)
You launch a second instance of IE.
You hold your breath.
If you're very lucky, the "Save Webpage" dialogue has now vanished from
the
first instance of IE.
Otherwise, you're hosed. ALL of your open tabs are dead because your
browser
went straight over the handlebars on colliding with one tiny hang in
downloading one miniscule web component -- a problem that IE has
absolutely
no trouble handling when it's just DISPLAYING a page rather than saving
it!
Is this a simple bug in the Save Webpage dialogue box?
Is this because IE doesn't bother to quarantine Tabs from each other?
Is this because IE does not bother to cache a page before it actually
starts
writing the downloaded file to the proper directory?
Whatever it is, I wager this is the #1 IE bug at which users are hurling
epithets on a regular basis.
Please fix it -- and if you aren't going to, please EXPLAIN what the
problem
is here. It's ABSOLUTELY INTOLERABLE.
All you
----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow
this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=952ad09b-03dc-4172-b330-990c09fd0844&dg=microsoft.public.internetexplorer.beta
rob^_^
2009-12-01 12:56:46 UTC
Permalink
Hi,

Have you tried View>Style>No Style then File>Print - Select PDF or XPS
printer?

The root of that issue is caused by too many positioned divs.

Regards.
Post by cyberyetti
getting this problem too. Not with txt or complete html saves though. Running
Vista Ultimate x64 SP2 with ie8 defender and windows firewall off as AVG 9
on. Not reproducible in Opera, Firefox, Safari or Chrome. Thinning hair
getting thinner by the day. BTW killiong just the appropriate thread with
process explorer (or task manager) restores ie8 to working condition but
doesn't save the page. Is there a good save as PDF about? that should clear
this up in a way.
Post by The Shadow
Hey, sorry I took so long. I solved my problem, so I took my sweet old time
getting to my previous post.
In my case it was my ZoneAlarm firewall that was causing the prolem. I got
fed up with it, uninstalled it, used Windows firewall with Avast Antivirus,
and have happy ever since. It also cut my boot time by about a quarter.
Try turning off your firewall, and use Windows Defender. If that does not
work uninstall your firewall, and at least temporarily stick with the Windows
firewall. In my instance, even turning off ZoneAlarm did not fix the problem.
As such, I do not know what ZoneAlarm was doing, but it was causing an
annoying problem even after turning it off.
Hope this helps. :)
Post by a.k.a.
Joe, I can concurr with the slower internet connections -- WiFi in my case.
IE just waits interminably, and unresponsively, for packets it won't get, and
I don't get why the Save dialogue can't break it.
Just wondering, Joe, are you running IE in Administrator accounts in Vista?
I'm asking because I don't think it's exclusive to Admin, but I think it's
more replicable in Admin.
I've noticed that IE prioritizes cookies differently between Admin and
normal users. In Admin accounts or settings, the cookies from other tabs
don't pop up on your current tab view. They just silently blink orange, and
this can crash IE too, because there are occasions when the cookie request
box never materializes. The GUI works fine, but the browser engine crashes,
and you have to restart to reconnect.
My experience with the UCLA site hang below could have been a similar
situation. Sitecounter wanted to send a cookie, and the Save Webpage process
had better things to do than respond to that request, so the save hung on it.
I do think this Save Webpage crash happens in non-Admin mode as IE bogs down
in a session. But at least in non-Admin mode, the cookie requests from other
tabs show up on your current tab, and are more likely to all get handled
appropriately.
THANK YOU for adding to this thread! It's important to get eyewitness
corroboration. Can you do me a favor and mark all of the posts in this thread
as "Useful." Only when the count goes up does this get passed along. Also,
did you see the threads in the IE7 forum and mark them useful?
This bug submission process is also a bit buggy.
a.k.a.
Post by Joe
I have had this happen on XP x86 with IE7, on Vista x86 with IE7 and IE8, and
on Windows 7 with IE8. Doesn't really matter what security mode the browser
is in, and the problem becomes moe frequent on slow internet connections.
Please fix it and stop IE8 becoming another joke.
Post by a.k.a.
Rob,
Another case where IE7 just hung is on a GIF-rich page. This was a .EDU
site, so nothing pernicious. IE either failed to send the proper command to
the server, the request packet was lost in transit, or the server failed to
send the information. (The server has not been slow to respond on other
occasions, so it is more likely one of the first two.)
There was no 3rd party cookie involved.
In this particular instance, clicking the Cancel and Red X buttons (over and
over) did absolutely nothing. IE had definitely hung.
But as I noted in my first post, launching a second instance of IE "over"
the first one made the Save Webpage box disappear.
This is the site. I doubt you'll be able to get it to reproduce the hang,
http://www.ats.ucla.edu/stat/r/modules/exploring_w_graphics.htm
Post by a.k.a.
Hello, Rob,
Thanks for responding. The details you asked for are below. But
the crucial
point is that this is a KNOWN bug seen by many IE7 users (and it's subtle
enough that I believe it's experienced by far more users than the small
percent of power users who report it). That's why I'm raising it
here -- I
haven't seen anyone mention it in regards to fixing it for IE8 so
far, and
this browser behavior drives me absolutely bananas when it kills
off every
open tab you're using, so it's definitely time to raise this with the dev
team! Please don't hear this as a criticism in any way, Rob: What
is worth
noting here is that if you haven't heard about this before, it indicates
there hasn't been a fix yet.
Let me point you to two threads in the IE7 forums that
acknowledge this as a
longstanding problem -- from early 2007 versions through December
of 2008!
(Make sure to at least read Lloyd GM's response on the first thread for a
good overview.)
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=f72b4bd5-38e3-468f-828d-5490ba20df52&sloc=en-us
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.internetexplorer.general&mid=475cb50c-4dca-408f-bfec-024ae0f32958&sloc=en-us
I am running Vista x64, and IE build 7.0.6001.18000, but other people are
reporting it on XP as well -- as late as December '08. (I remember this
happening to me in IE8 as well, but I was so scared away by the
crash rate in
IE8 that I'm waiting until IE8b3 to reinstall it.)
Is this reproducible in 'no-add-on mode'? No, but not for the reason you
expect. The problem is that this is always random, because it is
obviously
brought on by server-side timeouts, which are by nature erratic and
non-reproducible even under fixed client-side conditions. What people are
1. The user Saves the webpage in MHT format.
2. The webpage being saved has a 'no caching' request in the code.
3. There's a timeout on the server side.
Under those specific conditions, IE7+ always keels over dead.
Somehow, the
Save Webpage dialogue box at that stage becomes non-responsive to any
command.
Other people have suggested that the Phishing Filter is
implicated as well.
Someone else wants to also implicate a registry entry for
download locations.
(It's all in those two past threads.)
The fact is that Opera never fails an MHT save like this. IE7+ does.
None of us have any idea why it's not universally reproducible, but I
believe there are a lot of users out there with this problem.
Partly there's
under-reporting because it just seems to come with the territory of a
molasses-slow save rate for many MHT files. (99% and holding....
Cross your
fingers!) So in my case, for instance, it didn't even occur to me
to revive
this as a known bug until just now. I'd just assumed it was
widely understood
that IE was buggy to the point of crashing on MHT saves.
There's no reason that IE should force us to kill it when a save
stalls out.
Surely that can be added to the list of required fixes for beta 3!
Thanks!
Post by rob^_^
Hi aka.
Please always state your OS version and service pack level and
whether the
problem is reproducible in no-Addons mode.
Regards.
Post by a.k.a.
Hi IE Team and MVPs -- I know you have your hands full, but I
haven't seen
this mentioned so far, and I am really going to lose it if
this hasn't
been
fixed by the release of IE8....
You want to save a webpage to HDD, in MS' proprietary default
(.MHT) file
format.
You watch as the "Save Webpage" dialogue box appears. The
green bar
gradually creeps along toward 100%.
You hold your breath.
But it stalls out as the page begins to load -- anywhere from
12% to 99%.
You press cancel. Nothing happens. (Nothing EVER happens when
you press
cancel if you don't catch the save dialogue within the first
nanosecond
that
it appears.)
You click the close X. Nothing happens. (Nothing EVER happens.)
You launch a second instance of IE.
You hold your breath.
If you're very lucky, the "Save Webpage" dialogue has now
vanished from
the
first instance of IE.
Otherwise, you're hosed. ALL of your open tabs are dead
because your
browser
went straight over the handlebars on colliding with one tiny
hang in
downloading one miniscule web component -- a problem that IE has
absolutely
no trouble handling when it's just DISPLAYING a page rather
than saving
it!
Is this a simple bug in the Save Webpage dialogue box?
Is this because IE doesn't bother to quarantine Tabs from
each other?
Is this because IE does not bother to cache a page before it
actually
starts
writing the downloaded file to the proper directory?
Whatever it is, I wager this is the #1 IE bug at which users
are hurling
epithets on a regular basis.
Please fix it -- and if you aren't going to, please EXPLAIN
what the
problem
is here. It's ABSOLUTELY INTOLERABLE.
All you
----------------
This post is a suggestion for Microsoft, and Microsoft
responds to the
suggestions with the most votes. To vote for this suggestion,
click the "I
Agree" button in the message pane. If you do not see the
button, follow
this
link to open the suggestion in the Microsoft Web-based
Newsreader and then
click "I Agree" in the message pane.
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?mid=952ad09b-03dc-4172-b330-990c09fd0844&dg=microsoft.public.internetexplorer.beta
Loading...