282.00 KB, video/avi
46.15 KB, text/html
4.45 KB, patch
|Details | Diff | Splinter Review|
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
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
This is not a bug with ff but a bug with the web page. Please reopen if have more details implicating mozilla products.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
"This is not a bug with ff but a bug with the web page." And where is the bug in that page ?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
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?
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
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
Created attachment 179625 [details] 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
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.
Version: unspecified → Trunk
Created attachment 179638 [details] 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 .
Attachment #179638 - Attachment description: W3C markup verification results → W3C markup verification results and source of page
works seamonkey 1.8 2004112906 fails seamonkey 1.8 2004120304
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).
Assignee: firefox → parser
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: General → HTML: Parser
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → mrbkap
Hardware: PC → All
13 years ago
Assignee: parser → mrbkap
Created attachment 179742 [details] [diff] [review] 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.
Summary: Firefox fails to load pages when clicking on an "offer" (german: Angebot) → An <iframe> before a <frameset> makes the <frameset> fail to render
Comment on attachment 179742 [details] [diff] [review] patch v1 r+sr=bzbarsky
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).
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago → 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.