288991 - An <iframe> before a <frameset> makes the <frameset> fail to render

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[tilmaen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050404 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050404 Firefox/1.0+

When clicking on an offer (in the Last Minute section, for example) to view the
details, the browser fails to load the page. All you get is a white screen and
the status says "done".
following is an URL that didn't work
http://www.expedia.de/daily/LastMinute/suche.asp?rfrr=-40492&pid=3&type=654&url=http%3A%2F%2Fwww%2Evidado%2Ecom%2Fbooking%2Fexpedia%2Findex%2Ephp4%3FKID%3D360010%26detail%3Dhotel%26showresult%3D1%26topRegion%3D6%26personen%3D25%3B25%26termin%3D01%2E05%2E2005%26ruecktermin%3D26%2E06%2E2005%26dauer%3D1%26kategorie%3D1
however, the url might just not be availible in a couple of days, because it is
a travel offer for a specific time.

Reproducible: Always

Steps to Reproduce:
1.go to expedia.de
2.click on all inclusive, last minute or some other category
3.

Actual Results:  
nothing. blank page

Expected Results:  
the page should have shown up - showing the details of the travel offer

Comment 1

[tilmaen]

when showing the page source of the link in the details section and closing the
"show source" (strg+U // ctrl+U) window, the browser crashes (reproducable). the
link is/was
http://www.expedia.de/daily/LastMinute/suche.asp?rfrr=-40492&pid=3&type=654&url=http%3A%2F%2Fwww%2Evidado%2Ecom%2Fbooking%2Fexpedia%2Findex%2Ephp4%3FKID%3D360010%26detail%3Dhotel%26showresult%3D1%26topRegion%3D6%26personen%3D25%3B25%26termin%3D01%2E05%2E2005%26ruecktermin%3D26%2E06%2E2005%26dauer%3D1%26kategorie%3D1

Comment 2

[Gabriel Chadwick]

This is not a bug with ff but a bug with the web page. Please reopen if have
more details implicating mozilla products.

Comment 3

[Matthias Versen [:Matti]]

"This is not a bug with ff but a bug with the web page."
And where is the bug in that page ?

Comment 4

[Steve England [:stevee]]

Are you using an adblocker? Only I notice that some of their URLs start with
"ads.expedia" and they might get blocked. Have you tried with a new profile?

Comment 5

[Carsten Book [:Tomcat]]

WFM with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7)
Gecko/20050404 Firefox/1.0.3 but failed to load the page also with Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050404

Comment 6

[tilmaen]

No, i removed adblock from my plugin list for exactly that reason. no help
though :-(. i created a little avi that shows the problem - gonna attach it here
by tilmaen

Comment 7

[tilmaen]

Attachment: this is a video of what happens when you open the described page and view the source (+close it)

sorry about the quality - had to recompress 2 times to get to 300 kbyte

Comment 8

[Gabriel Chadwick]

Sorry did not do  a good analyse and I was testing this bug with the latest
build. Sorry.  I confirm this bug in Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.8b2) Gecko/20050404 Firefox/1.0+ . But not in the 1.0.2 . Could this
be a regression ? In order to confirm this bug we have to find what is the
component and product causing this bug.

Comment 9

[Gabriel Chadwick]

Attachment: W3C markup verification results and source of page

Here are the W3C markup validation results. They are very evident. This page is
not valid. The only thing i don't understand is why is it not working in trunk
but it is working in 1.0.2 .

Comment 10

[Steve England [:stevee]]

+kw regression

Comment 11

[Bob Clary [:bc] (inactive)]

works seamonkey 1.8 2004112906
fails seamonkey 1.8 2004120304

Comment 12

[Boris Zbarsky [:bzbarsky]]

In fact, this broke between 2004-11-30-08 and 2004-12-01-08.

Looking at the DOM, the "working" builds show the frameset, while the "broken"
builds just show the iframe (which is display:none).

Blake, this looks like bustage from bug 88952 (which landed in the date range in
question).

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch v1

The problem was that we were pushing the <iframe> onto the misplaced content
stack, but there was a text token following the <iframe>. Since text tokens
request that a body be opened, this opened the <body> and the frameset failed.
With this patch, when we push an <iframe> that's guaranteed to have a text
token after it, we also push all of the tokens related to the <iframe> onto the
misplaced content stack.

This could potentially fail if the user has frames turned off (an iffy
proposition to begin with) and there's an iframe to the effect of
<iframe>hello</iframe>, but I feel for 1.8b2, this is the best fix.

There's also some duplication of logic between OpenContainer and
IsAlternateTag() (specifically the code that sets
NS_DTD_FLAG_ALTERNATE_CONTENT). I could make this code use IsAlternateTag() if
it's felt to be necessary.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 179742 [details] [diff] [review]
patch v1

r+sr=bzbarsky

Comment 15

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked in.

For the record, attaching videos of navigating around (even in crash situations)
or the validation pages are not terribly helpful. It's a lot more useful to
attach either a copy of the page, or even better, a reduced testcase (see
http://www.mozilla.org/newlayout/bugathon.html#testcase).