Page renders browser unusable

VERIFIED WONTFIX

Status

()

P2
normal
VERIFIED WONTFIX
19 years ago
18 years ago

People

(Reporter: braden, Assigned: harishd)

Tracking

({testcase})

Trunk
x86
All
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+] [strict dtd])

Attachments

(1 attachment)

154 bytes, text/html
Details
(Reporter)

Description

19 years ago
Not sure what the component should be. Attempting to load this page appears to
render the application unusable. Doesn't actually bring down the app, but
effectively a crash. Page in question to follow as an attachment.
(Reporter)

Comment 1

19 years ago
Created attachment 11712 [details]
Test case
(Reporter)

Comment 2

19 years ago
Oh yeah... This is build 2000072108.
Keywords: crash

Comment 3

19 years ago
HTML element  the test case is this:

<select><option label="1">One<option label="2">Two<option label="3">Three</select>

Assignee: asa → clayton
Component: Browser-General → HTML Element
QA Contact: doronr → petersen
There are two problems here.

1. The test case is confusing the hell out of our Strict DTD.
2. When a page cannot be displayed, Gecko doesn't draw anymore.

The second is almost certainly covered elsewhere (bug id anyone?) so lets 
focus on the first issue here.

-> Parser.

Nominating for nsbeta3 because of poor user experience. This is not 
a 'correctness' issue -- the HTML is invalid. It's not a crash, the browser 
stands solid but gecko stops drawing. It's not a leak, it's not a ui issue,
it's not a polish issue (it's rather more important than a polish issue!)...
Assignee: clayton → rickg
Severity: critical → major
Component: HTML Element → Parser
Keywords: crash → nsbeta3, testcase
OS: Linux → All
QA Contact: petersen → janc
(Reporter)

Comment 5

19 years ago
Yup... I stumbled onto this one by accident. :-)

I don't know what the verdict is as far as the browser's response to invalid
documents that claim to be 4.0 Strict--IMO, an error message would be
sufficient. In other words, I don't know that 1 is a problem. As far as 2 goes,
the current behavior ("freak out") is obviously unacceptable. :-)

If 2 is documented elsewhere and there is agreement that 1 isn't a problem, this
can probably be marked as a duplicate.
The first is a problem because even with blank documents, the parser should be
creating a content model. With this page, it freaks out completely, which is
wrong wrong wrong. (Of course, there is also the additional problem of what to
do when we *do* freak out, but that is a separate issue.)
(Assignee)

Comment 7

19 years ago
Assigning to myself since rickg is on sabbatical.
Assignee: rickg → harishd

Comment 8

19 years ago
This should be an easy fix according to Harish.  We will make it so that the 
parser always opens up a body so that a blank page gets displayed in such cases.
Severity: major → normal
Status: NEW → ASSIGNED
Priority: P3 → P4
Whiteboard: [nsbeta3+]
(Assignee)

Comment 9

18 years ago
Setting priority to P2.
Priority: P4 → P2
Target Milestone: --- → M18

Updated

18 years ago
Whiteboard: [nsbeta3+] → [nsbeta3+] [strict dtd]

Comment 10

18 years ago
Marking wont fix -- we're removing strictDTD support in 6.0.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 11

18 years ago
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.