52533 - Browser dies when trying to edit a page

Status: VERIFIED INVALID

(Core :: DOM: Editor, defect, P3)

Description

[Jorge Martinez]

The browser dies (all windows that were open close) when I try to edit <a
href="http://www.unixreview.com/development/articles/9908f1dw.shtml">this
page</a>. I noticed that it happens right after the edit window opens, either
when I move the mouse, or try to resize the window, etc.

Regards,

Jorge M.

Comment 1

[sujay]

yes I can reproduce this on linux...does not crash on windows...

Comment 2

[James Green]

WFM Linux 091908. Anyone else verify?

Comment 3

[Charles Manske]

Worksforme on Windows NT today with my debug build: 2000091312

Comment 4

[rubydoo123]

that is hands down one of the worst constructed web pages I have ever seen.
There are close to a dozen html start and end tags interspersed within table
elements, end form element that is misplaced, and other such things. Clearly an
extremely malformed file. Granted we should not crash, but this is clearly an
edge case. Will try to clean it up and attach to see if the cleaned up file
crashes on linux

Comment 5

[Asa Dotzler [:asa]]

Setting bug status to New.  Bugs whaich have been triaged to a target milestone
should not be Unconfirmed.

Comment 6

[rubydoo123]

no, this has not been confirmed, i indicated that we need information before
confirmation, please leave the status as unconfirmed for just those reasons

Comment 7

[Asa Dotzler [:asa]]

This bug has a confirmation

------- Additional Comments From [e-mail] 2000-09-13 14:42 -------
yes I can reproduce this on linux...does not crash on windows...

and a Target Milestone.  The Unconfirmed state is to protect developers from
worthless bugs not to discriminate against those unfortunate bug reporters
without a netscape.com email address.  A bug which crashes us, under any
circumstances, that has been reproduced should not sit in the Unconfirmed state.
 When _every_ bug starts off Unconfirmed (Including the scores of Invalid,
Worksforme and Duplicate bugs filed by netscape empleyees) then I will agree
that a bug should stay Unconfirmed until we have fully triaged it.  But in this
case we have a report which had sufficient information to reproduce a crash.  I
can see no reason why it should stay unconfirmed.

Comment 8

[sujay]

hey guys, Bugzilla is going haywire..I did not enter that last commment above.

I have no idea how that got there....

Comment 9

[Blake Ross]

I think Asa posted your earlier comment in the middle of his post to show that 
someone (you) confirmed the crash to exist...

Comment 10

[rubydoo123]

ok, let me reiterate one more time -- as long as a bug is under investigation,
and I have explicitly requested additional information -- leave it as
unconfirmed -- need info means I am attempting to confirm the issue, regardless
to what any other individual reports. It is unconfirmed until the root of the
problem is found, by moving it to new or assigned, you just took it off my
investigate radar. If you are not the 1. owner of the bug, or 2. someone who is
helping to provide a reduced testcase and provided one -- leave the status alone.

Comment 11

[Asa Dotzler [:asa]]

I disagree that "It is unconfirmed until the root of the problem is found..."
There are thousands of bugs filed every month which start off as New because the
reporter happens to have a permission switch flipped on his/her Bugzilla
Account.  Hundreds of those bugs are written off as WFM, Invalid, and duplicate
and most of the ones which are not bad don't start off with the root of the
problem included in the report.  There should be no difference between a well
reported and reproduceable bug filed by a netscape contribuotor and a well
reported and reproduceable bug filed by a non-netscape contributor.
"by moving it to new or assigned, you just took it off my investigate radar." So
you don't investigate bugs filed by people with the Can Confirm Bugzilla
permission.  Unconfirmed is an ineffective and impractical "needs investigation"
radar.  The Unconfirmed state was created to shield developers from what was
expected to be a flood of poorly written bug reports that we thought would
result from the exposure of Netscape's PR1.  It was not created to put well
written bugs filed by non-netscape contributors in a some other class from those
filed by netscape employees.
There is a large group of volunteers working in Bugzilla to keep the Unconfirmed
state from becoming a black whole.  We process hundreds of Unconfirmed bugs each
week, clearing out duplicates, invalid and worksforme bugs and confirming and
even testcasing good bugs so that developers can focus on fixes and not waste a
lot of time looking at unhelpful bug reports. We aren't going to leave the
status of Unconfirmed bugs alone.  I apologize if I confused you by confirming
this report and will try to ammend my Unconfirmed queries to exclude bugs where
you have [need info] in the status whiteboard but I strongly disagree with your
assertion that only an owner or someone willing to testcase a bug can Confirm
it.  This product would be in far worse shape than it is without the efforts of
those contributors that you would exclude from the process.

Comment 12

[rubydoo123]

moving to future, this needs to be reduced and tested before any recommendations
can be made

Comment 13

[rubydoo123]

accepting to get rid of that annoying bugzilla reminder

Comment 14

[kinmoz]

Hmmm, the sample URL:

    http://www.unixreview.com/development/articles/9908f1dw.shtml

is no longer available.

I'll take this bug off of beppe's plate. If anyone can give me the page or 
something that causes the same crash, I'll debug it.

Comment 15

[Kathleen :Brade]

Move to Future and possibly resolving as Invalid at some future date if we can't 
find a file to reproduce this crash.

Jorge Martinez--if you can reproduce it, please attach a file or provide a new 
URL.  Thanks!

Comment 16

[Blake Ross]

marking invalid.

Comment 17

[sujay]

verified.