IE8 videos on Channel 9
Myself as well as some other people from the team recently sat down with Charles Torre from Channel 9 to talk about IE8. We thought you might enjoy these:
You can check out all the IE8 related videos on Channel 9 here. There are also some interesting IE8 “How Do I” videos on MSDN.
Thanks!
Sharon Cohen
Program Manager
Comments
Anonymous
February 26, 2009
PingBack from http://seven-lotus.net/videos/no-categories/ieblog-ie8-videos-on-channel-9/Anonymous
February 26, 2009
Hello are a date there of official final release?Anonymous
February 26, 2009
Enough with presentations; we don't need videos but the "real thing". If IE8 has reached RTM, please release it.Anonymous
February 26, 2009
Although i am Microsoft Fans, but... I install safari 4 this day(i use this broswer 1st time), the response is awesome rather IE, I and my customer had encounter the IE suddenly stopped, whenever I'm a exprienced IT Guy and I applied the best Practices advice by MS for my machine, I will still use my IE-7 as my default broswer, but I really looking for the new IE-8 give us a awesome rather than safari and others TeddyAnonymous
February 26, 2009
Hey Now, Great vids! Thx 4 the info, CattoAnonymous
February 27, 2009
The comment has been removedAnonymous
February 27, 2009
Nice videos - Bad audio! They are all recorded in Mono! Which is a PITA to listen to with headphones on.Anonymous
February 27, 2009
The comment has been removedAnonymous
February 27, 2009
A ways back in the IE7 beta cycle, TLS extensions were added so virtual host providers could use the SNI extension ("Server Name Indication" ) for TLS https traffic, thereby not wasting an IP for every hostname. Unfortunately, that only happened on Vista. Any chance this could be supported across all versions IE regardless of the version of the underlying OS? Most people still have XP unfortunately, which dates back to 2001.Anonymous
February 27, 2009
@sroussey: Sorry, TLS support in IE is provided by the operating system's platform DLLs (e.g. schannel.dll) which are not a part of IE. Windows XP will not support TLS extensions now or in the future.Anonymous
February 28, 2009
The comment has been removedAnonymous
February 28, 2009
@Fred: For what it's worth, the "Linkify" applet in IEToys does what you're looking for. http://www.enhanceie.com/ietoys/Anonymous
March 01, 2009
Fred: Check this out: http://www.ieaddons.com/en/details/other/Preview_and_Launch_URL/ ;DAnonymous
March 01, 2009
I echo the RC2 request by steve_web, especially with the phrase "a browser that WE will have to support for the next 10-12 years". I realize that IE9 is probably going to come sooner (3 years?), but unless Windows 8 comes out in 3 years from now, many people will not upgrade to IE9 when it comes out, but will keep IE8 since it comes with Windows 7 (and all of that assumes Windows 7 and IE8 are going to be successful and highly installed) However, as it can be seen by the bug entry https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=415158 the MSIE team explicitly DENIED that request (two days ago). And BTW, this is just the tip of the iceberg of issues, though arguably, the tip is the most sencetive part (yeah, I've watched the Colbert Report recently).Anonymous
March 02, 2009
http://www.neowin.net/news/main/09/02/23/internet-explorer-8-has-reached-rtm Asking for another RC is useless when it's already reached Gold/Final/RTM status. Microsoft and the IE team doesn't care one bit about standards compliance, regressions or code quality at all. All they care about is releasing on time for Windows 7 since we've all see the miserable failure of Vista, totally rejected by the consumer and business markets.Anonymous
March 02, 2009
@Sage : http://blogs.msdn.com/ie/archive/2009/02/20/rescheduled-february-chat-with-the-internet-explorer-team.aspx#9441744Anonymous
March 02, 2009
It would be great if they would fix the Lock toolbar function before release. If I drag my toolbars around and then try to lock them in place (including add-on toolbars), instead of staying where I put them, they go back to the default positions.Anonymous
March 02, 2009
The comment has been removedAnonymous
March 02, 2009
@security failure Nice one! I can confirm it happens on my PC (Internet Explorer 7, windows XP and Media Player 11 and Firefox 3) I don't use IE very much at all but it was pretty disturbing to see all kinds of history in IE that I most certainly did NOT open or look at in IE. I view medical records (patient videos) in Firefox on a shared computer. There is nothing overly private about the contents (the file IDs do not indicate the patient directly) but I don't think any other users of the computer need to look at infections or surgery details while browsing for a place to eat. I guesss now I will have to open up IE and clear the IE cache after I finish cataloging in Firefox in order to ensure that no one is accidentally grossed out. emanuelAnonymous
March 02, 2009
I hate to say it but, I switched from IE 8 RC1 to Apple Safari Beta. I made this switch because IE 8 RC1 seems to crash all the time since the RC has been released. I have tested it since it was first released as Beta 1. It had some bugs in it, but now, it just plain crashes all the time. Beta 2 was much better, and it loaded webpages faster. I like Safari Beta because it loads pages faster then IE8. Anything that can do this is a plus for me! I am an avid Microsoft fan. I love the products that they have produced in the past. Heck, I even bought Windows Vista when it first came out. But, when my web browser crashes all the time and loads webpages slower then it did in Beta 2, then there is a problem (I even formated my PC to see if that would fix the problem). If you guys fix these problems, IE8 could be the best version of IE that has ever been released. Until these problems are fixed, I am going to keep using Safari and I am going to recommend Safari to my customers. (I hate FireFox because it crashes when I use it.) Please, impress your everyday Microsoft Internet Explorer users!Anonymous
March 02, 2009
The comment has been removedAnonymous
March 02, 2009
@Lee /@Emanuel: Sorry Lee you are wrong, way wrong. The situation is this. Either Windows Media Player or IE is to blame, not Firefox (or any other browser because it happens in ALL of them (I just tested in Opera and Safari). Do this: 1.) Open IE, completely obliterate any history/cache. 2.) Close IE. 3.) Open a local video file off your hard drive ("pretend" you downloaded it) in Windows Media Player 4.) Now - Verify your Windows Media Player settings are set to NOT keep a history of urls/files loaded. (in the options dialog) 5.) Close Windows Media Player. === AT THIS POINT THERE SHOULD BE NO HISTORY OF THE VIDEO YOU JUST WATCHED - NONE === 6.) Open up Internet Explorer (any version) and do a CTRL+H to open the history panel. 7.) Open the "Today" section... WT*!?!?! Blame anyone you want but don't bother blaming Firefox - because (in the example above) Firefox wasn't even used!!!!! This is a serious privacy issue in Internet Explorer (or Windows Media Player) or both. Absolutely needs to be fixed AND backported to IE7 (if an IE bug) or a patch is needed for all current versions of Windows Media Player (if it is the guilty party) @Security Failure/@Emanuel - thanks for posting the bug/confirming the bug. @Microsoft - if this is a WMP bug will the patch be served up using automatic updates? if so at what level? Critical or just Serious? buenosAnonymous
March 02, 2009
@melvin, can't repro the problem you're describing here (XPSP2+WMP11). What version of Windows and what version of WMP? Either way, it's not an IE bug, since IE is clearly just exposing state known to the shell. It's not like IE starts up every time you play a local video.Anonymous
March 02, 2009
@Dan & melvin I can reproduce it on my 2 computers: a) WinXP Service Pack 3, WMP10 (IE7) a) WinXP Service Pack 3, WMP11 (IE8) I should note that my settings for WMP were to not save a history (and) I didn't click the clear history button (since I didn't have the save history checkbox checked) seems a patch is in order for Windows Media Player (10 & 11) does anyone have WMP 9 still?Anonymous
March 02, 2009
OMG! big time privacy bug! It shows my history in IE too (IE8 Release Candidate 1) and Windows Media Player 10 Houston we have an Epic Fail!Anonymous
March 02, 2009
Cannot replicate /w XPSP3, IE7, and WMP11. Nothing in "Most Recent Documents" or in the "History" pane of Internet Explorer or Windows Explorer. That said, with the way it's worded they can technically get away with it in 11. It says "Save file and URL history IN THE PLAYER". It doesn't appear to have a control for whether or not it has a history, period. Put away the "epic fail". In fact, go send it to "die in a fire" with other equally annoying phrases.Anonymous
March 02, 2009
I can reproduce the bug but it sometimes fixes itself if I check/uncheck the option in WMP (10). I think it is an issue with WMP not IE but I wonder what else does Windows save about files that have been opened. IMHO this is exactly why embedding IE in Windows was a horrible mistake. I'm so glad my Firefox is not embedded in Windows.Anonymous
March 02, 2009
IE is not embedded in Windows. Trident is. And the majority of people that don't want Trident embedded in Windows don't really know what they're talking about. Making people provide/create their own HTML container in these times is tantamount to making people provide/create their own text container and similar. Out of interest along those lines, would it actually be possible for Mozilla/etc to write up a version of Gecko/etc implementing the APIs that applications call Trident with and slot it into Windows seamlessly?Anonymous
March 02, 2009
@steve_web >* CSS 2.1 :hover:focus doesn't work Is it :hover:focus ... or is it :focus:hover which is bug 418495 connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=418495 Please make that utterly clear because, over here, www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/bug418495-multiple-focus-hover-classes.html is rendered correctly and without a problem. >* onresize events STILL don't fire properly on iframes (broken since IE8 Beta 1) Steve, if you can not provide a reduced testcase for that one and any other presumed-bug that you very much care for, then how do you expect others - that you often assimilate to "we" - to validate+vote for such bug(s)? Again, a short description is not a reduced testcase (which can answer a lot of questions), is not a bug report id number, is not as useful as an url, etc... Where have you read/seen that IE Team does not intend to fix or will not fix your onresize iframe bug? >* getElementsByName( name ) is still broken in IE8 Standards mode getElementsByName( name ) is not widely used and it will be fixed with the next release of IE (fixing DOM 2 HTML bugs, DOM 2 Core bugs, implementing DOM 2 Events). Why should IE 8 not be released because of a bug in getElementsByName( name )? I'm sure there are workarounds possible for this. >* CSS 2.1 :hover not supported on select lists Please explain why select lists reacting on :hover is a serious enough lacking feature to postpone IE 8 release and to have a RC2. I can not believe you are demanding for this bug to be fixed in a RC2. " report any critical issues (e.g., issues impacting robustness, security, backwards compatibility, or completeness with respect to planned standards work). Our plan is to deliver the final product after listening for feedback about critical issues. We will be very selective about what changes we make between the next update and final release. We will act on the most critical issues. We will be super clear about product changes we make between the update and the final release. " blogs.msdn.com/ie/archive/2008/11/19/ie8-what-s-after-beta-2.aspx > * wicked rendering glitches when displaying floating content in tables > * wicked rendering glitches when changing borders via :focus CSS near tables inside web slices Bug report numbers for those 2? Testcases URLs? GérardAnonymous
March 02, 2009
The comment has been removedAnonymous
March 02, 2009
@Gérard Talbot >* CSS 2.1 :hover:focus doesn't work Is it :hover:focus ... or is it :focus:hover which is bug 418495 I'll verify. -- >* onresize events STILL don't fire properly on iframes (broken since IE8 Beta 1) Steve, if you can not provide a reduced testcase for that one and any other presumed-bug that you very much care for, then how do you expect others - that you often assimilate to "we" - to validate+vote for such bug(s)? Uhm... I could be wrong on this but I've filed several test cases for onresize not working (and I'm not the only one), and MSFT has reproduced each bug in house. -- Where have you read/seen that IE Team does not intend to fix or will not fix your onresize iframe bug? I didn't specifically say they did not intend to fix this bug. -- >* getElementsByName( name ) is still broken in IE8 Standards mode getElementsByName( name ) is not widely used... Uh... this is a catch 22 situation. It CAN'T be widely used UNTIL it is fixed because the browser with 2/3rds of the market didn't implement it correctly. However the SOONER it is fixed, the sooner developers can safely make use of it. -- >* CSS 2.1 :hover not supported on select lists Please explain why select lists reacting on :hover is a serious enough lacking feature to postpone IE 8 release Lets digress for a moment here. Microsoft is making IE8 render in standards mode by default... fixing as much of their broken rendering, DOM, CSS and JavaScript as possible to make IE8 a great browser to develop/render the web on. Currently in IE8 RC1, the following things are broken on select elements. a.) the drop arrow doesn't render in XP themes it fails back to Windows95 rendering therefore looking broken and ugly b.) you still can't set the .innerHTML on a select element c.) you can't set the border on the select element d.) you can't set many styles on options within the select element e.) you can't set event handlers on the options in the select element f.) you can't alter the contents of the select list from an onclick or onfocus event on the select g.) and you can't use :hover on a select list so that it behaves exactly like all the other form elements on your page Agreed its one minor thing (on top of a pile of other minor things), but if MSFT wants to go public with IE8 as a Standards Browser touting we're CSS 2.1 compliant... I call bunk. (I need to go now, I'll respond to the other items in a bit) steveAnonymous
March 03, 2009
con't. regarding the MSFT statement when RC1 came out - yes I know how to read... but I (among thousands of others) do NOT feel that RC1 is of "Release Candidate" quality what-so-ever. A Release Candidate should be what you are ready to ship... pending any bugs that get reported during final testing. Since some of the most basic things are broken (e.g. you can't maintain a session in InPrivate using tabs), qualifying RC1 as the "final" Release Candidate is hardly correct. I know full well that Microsoft doesn't operate according to developers agenda's and that they have release dates they plan to hit one way or another. However it is my right to the opinion that IE8 RC1 is not Ready For Market, and moreso that us developers really deserve a build before RTM with the various stop-gap, showstopper bugs fixed so that we can adequately test, adjust our code to handle IE8 so that we are ready when it drops. -- As for the rendering glitches in IE8 with tables, floating content, and web slice (markup) I have posted a bug in connect and provided microsoft with video of the bugs in action. Unfortunately the content is private and therefore I can not post a URL. I don't have time this week to break down a simplified test case for each but if I get the chance next weekend I will certainly try. Don't get me wrong, I fully understand the need for simplified test cases and the ability to let others test and reproduce for verification... but we all know that Connect is not living up to that job and never has (I'm not going to add more to that rant now) Bug: 415687 steveAnonymous
March 03, 2009
The comment has been removedAnonymous
March 03, 2009
The WMP OPEN dialog shows the systemwide history list. You'll almost certainly see the same list in START>RUN, and anywhere else in the system that is using the same functionality: http://msdn.microsoft.com/en-us/library/bb759862(VS.85).aspx IE isn't tracking anything; IE is simply one of many ways to display state the system itself tracks.Anonymous
March 03, 2009
@ steve_web > I didn't specifically say they did not intend to fix this bug. People reading this blog may reach a different opinion than yours. You act as if they "STILL" have not fix such bug and that they did/do not intend to before final release. > It CAN'T be widely used UNTIL it is fixed because the browser with 2/3rds of the market didn't implement it correctly. It's true that it would be more frequently seen and used on the web if getElementsByName was working/implemented correctly to begin with: that's true. I still firmly think getElementById would be more frequently used than getElementsByName because only a very short limited list of elements can have a name attribute. And it's true that there are often a perfectly working, easy-to-figure-out, valid, web-standards workaround for such bug. >* CSS 2.1 :hover not supported on select lists Anyone can visit bug 416378 connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=416378 and then read your own bug report: it claims that "pseudo :hover :active :focus selectors don't work" ... but now, today, this bug has been reduced to 1 single element and 1 pseudo-class: select and :hover. So, you exaggerated. And you still exaggerate the importance of having such bug fixed. In bug 416378, there is no crash, no hang, no dataloss, no page layout breaking, no content missing, no loss of navigation functionality, no accessibility burden, no misalignment, no overlapping, no guillotine, etc,etc nothing, absolutely nothing serious, grave, detrimental, incapacitating, critical. > a.) the drop arrow doesn't render in XP themes it fails back to Windows95 rendering therefore looking broken and ugly So you are saying such bug is entirely a cosmetic issue then. > c.) you can't set the border on the select element Your whole webpage won't break because of that; users won't be helpless because they can't see the border on the select. select:focus {outline: 3px lime outset;} works in IE 8 RC1. Is that good enough for you? Anyway, this kind of bug is definitely not the type of bugs serious enough to postpone the final version of IE 8. > Microsoft is making IE8 render in standards mode by default... fixing as much of their broken rendering, DOM, CSS and JavaScript as possible That's not accurate. IE8 was supposed to provide full support for CSS 2.1 and to fix the most annoying, most incapacitating and impactful, most requested, most serious bugs in DOM Core and HTML interfaces, not all bugs in DOM interfaces. And as far as I'm concerned, I'd say the IE Team did that in a wide majority of cases. "We want to make IE8's Standards mode much, much better than IE7's Standards mode." Microsoft's Interoperability Principles and IE8 blogs.msdn.com/ie/archive/2008/03/03/microsoft-s-interoperability-principles-and-ie8.aspx Dean Hachamovitch, General Manager Internet Explorer, March 3rd 2008 "Our goal is to deliver complete, full CSS 2.1 support in the final IE8 product." Dean Hachamovitch, General Manager Internet Explorer, March 5th 2008 blogs.msdn.com/ie/archive/2008/03/05/internet-explorer-8-beta-1-for-developers-now-available.aspx "We probably won't be able to fix all of the community-reported bugs in the DOM in this release (there are many), but we want to make sure that we get to the worst offenders first." HTML and DOM Standards Compliance in IE8 Beta 1 Travis Leithead, Program Manager IE8 Object Model, April 10th 2008 blogs.msdn.com/ie/archive/2008/04/10/html-and-dom-standards-compliance-in-ie8-beta-1.aspx As for javascript, ECMAScript 3.1 is not completed and finalized... but I'm convinced IE Team is developing a javascript engine in parallel with the talks in ECMAScript 3.1. regards, GérardAnonymous
March 03, 2009
@ steve_web Visit those [pretty serious in my opinion] bug reports and vote and/or validate as you feel/wish: Bug 366200: document.write()ing "document.close()" into iframe freezes browser connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=366200 Bug 414807: [RC1 build 18372] [Reproducible CPU hang] Examining read-only properties in dev. tools maximizes CPU activity and hangs iexplore.exe application connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=414807 regards, GérardAnonymous
March 03, 2009
@Gerard "and then read your own bug report: it claims that "pseudo :hover :active :focus selectors don't work" ... but now, today, this bug has been reduced to 1 single element and 1 pseudo-class: select and :hover. So, you exaggerated" quite correct... I wanted to correct this afterwards but the title is not editable. Unfortunately in the mix of testing on various places (local system, local server, remote server) and the combination of doctypes, standards mode, IE8 standards mode, and the IE dev toolbar I managed to convince myself that I had seen the issue in IE8 when running in full IE8 standards mode... unfortunately I was wrong... and retracted the full severity shortly after.Anonymous
March 03, 2009
@Gerard: as for the Win95 rendering of select lists... yes it is cosmetic... but try explaining to a client that the ugly bug in THEIR application is actually MICROSOFT's fault. Oddly enough they don't believe you, nor do they care, they just want it fixed... therefore so do I. I would be seriously embarrassed to ship with this bug still in place.Anonymous
March 03, 2009
@Gerard: "Anyway, this kind of bug is definitely not the type of bugs serious enough to postpone the final version of IE 8." Agreed. Totally. IMHO, RC1 is NOT an Release Candidate. It isn't ready (again) IMHO. I want an RC2 because I feel that RC1 isn't up to par. Anyway, enough of the squabbling over details, I just want as many fixes as possible in IE8 before it ships. I think we can all agree that there is lots of work to be done.Anonymous
March 03, 2009
@ steve_web > try explaining to a client that the ugly bug in THEIR application is actually MICROSOFT's fault. Explaining to a client that such ugliness can be very subjective and very relative, is secondary to functionality, is very minor compared to stability, reliability, accessibility, etc... is actually part of your job, is actually part of your responsabilities. And it's entirely irrelevant whose fault it is. GérardAnonymous
March 03, 2009
@steve_web > IMHO, RC1 is NOT an Release Candidate. It isn't ready (again) IMHO. You have to trust IE Team to be competent, wise, smart enough to know/see that a few bugs (and determine which ones based on seriousness criterias) need to be fixed before shipping. > I just want as many fixes as possible in IE8 before it ships. Once RC1 has been released, the rules change and the rules are not "as many as possible" but only the most serious ones, the most impactful [regression] ones (like a crash), and those which would not require architectural re-design work. Read the quote from Dean Hachamovitch again: in 3 sentences, he repeats "critical issues" 3 times. " report any critical issues (e.g., issues impacting robustness, security, backwards compatibility, or completeness with respect to planned standards work). Our plan is to deliver the final product after listening for feedback about critical issues. We will be very selective about what changes we make between the next update and final release. We will act on the most critical issues. We will be super clear about product changes we make between the update and the final release." blogs.msdn.com/ie/archive/2008/11/19/ie8-what-s-after-beta-2.aspx GérardAnonymous
March 03, 2009
@Gerard Talbot The dev tools hangup they could even release after final as a patch. It does not influence user experience of any regular users.Anonymous
March 04, 2009
@ hAl Yes, they could release a patch after final release as it [Bug 414807] only affects dev tools. But shipping IE 8 final release with bug 366200 is difficult to understand.. and they had lots of time. regards, Gérard