Closed Bug 309587 Opened 19 years ago Closed 18 years ago

the page does not load

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha1

People

(Reporter: hramrach, Assigned: mrbkap)

References

(
URL
)

Details

Attachments

(1 file)

non-working wip
8.04 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050921 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050921 Firefox/1.6a1

When I type in the url, the page never finishes loading, and no content is shown.

In Safari or Shiira I can see a blank page with a green stripe at the bottom,
which is part of the actual content(accessible by scrolling the page).

Pages from ohter subdomains are visible without problems. But I am not sure they
are hosted on the same server.

Reproducible: Always

Steps to Reproduce:
Try loading the url in Firefox
Actual Results:  
No page loaded/displayed

Expected Results:  
Firefox should display the page content
confirming on Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050920
SeaMonkey/1.1a

The page loads in Opera, it also loads in Seamonkey, if JS is disabled. When JS
is enabled, after loading the page the window is cleared, the number 11011 is
displayed top left and endless loading starts. I didn't see warnings or errors
in JS console. If you watch the tab while the page is loading in the background
you shortly see a title before the page is cleared and the endless loading starts.
Invalid HTML, but that shouldn`t load endlessly, if JS is enabled.

if JS is enabled, endless loading:
        <tr valign="top"> 
          <td width="780" height="149" colspan="3"
background="images/index_07.gif" align="left" valign="bottom"><div
id="pocitadlo" class="counter"><script
src="http://www.blueboard.cz/counter_0.php?id=17372" language="JavaScript"
type="text/javascript"></script></div></td>
        </tr>

Validator tells:

http://validator.w3.org/check?uri=http%3A%2F%2Fvimana.freetekno.cz%2F&charset=%28detect+automatically%29&doctype=Inline&ss=1
Sorry, I am unable to validate this document because on line 181  it contained
one or more bytes that I cannot interpret as us-ascii  (in other words, the
bytes found are not valid values in the specified Character Encoding).

         <a href="http://www.freetekno.cz/proglas.jpg" target="_blank"
class="linx">proglas ¬</a><br></div></td>

CSS:    http://vimana.freetekno.cz/style/main.css
SOURCE: view-source: http://vimana.freetekno.cz

The first 13 lines of the source are repeated, shown here are 13+5 lines:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Spiritual Sound System</title>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<link href="style/main.css" rel="stylesheet" type="text/css">
</head>

<body bgcolor="#DBE2BC" leftmargin="0" topmargin="0">
<table width="800" height="100%" align="center" cellpadding="0" cellspacing="0"
border="0">
	<tr valign="top">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>

<head>
<title>Spiritual Sound System</title>
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050920 SeaMonkey/1.1a

confirming as HTML Parser, or is it a DOM bug?

First n lines of the document are repeated, so the document starts again in a
<tr>. Is this allowed, or mustn't it be a frame or iframe then?

There is one script in this document, referring to a counter. If JS is enabled,
the script clears the screen and loading indicator doesn't stop, though Firefox
displayed 'Halted' in the status line. It isn't a recent regression, I've seen
the bug on Fiorefox 1.0.6 also.
Assignee: darin → mrbkap
Status: UNCONFIRMED → NEW
Component: Networking → HTML: Parser
Ever confirmed: true
OS: MacOS X → All
QA Contact: benc → parser
Hardware: Macintosh → All
The problem here is the <link> inside the misplaced content (<tr><link>, in this
case). We lose the request to block the parser because we never check the result
(see
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/parser/htmlparser/src/CNavDTD.cpp&rev=3.467&mark=1906#1906).
I'll try to patch this soon.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.9alpha
Attached patch non-working wip — — Splinter Review 
This is a start, but it is nowhere near completion. For one thing, multiple <link>s that want to block the parser would murder this approach, for another, all potential callers of HandleSavedTokens need to be ready to stop what they're doing and block the parser. This is an unfortunately difficult problem.
Could this happen with <script> too?  Or just <link>?
Depends on: 84582
<script> is allowed in <table>, so we wouldn't be processing it under HandleSavedTokens.
So is there a testcase that shows the problem?  Or does the original site still show it?  I see something in current builds...
(In reply to comment #8)
> So is there a testcase that shows the problem?  Or does the original site still
> show it?  I see something in current builds...

I wonder if the patch in bug 308145 fixed this.
The original page still shows the problem in Firefox 2.0.1

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20070213 Firefox/2.0.0.1
OK.  Well, builds from before bug 84582 show the same thing as branch (which is _not_ "no content").  Builds after that point show something entirely different.  Sounds like this is fixed.

By the way, I strongly suggest upgrading from Firefox 2.0.1 to Firefox 2.0.3 -- the has known security issues
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: