If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Browser dies when trying to edit a page

VERIFIED INVALID

Status

()

Core
Editor
P3
major
VERIFIED INVALID
17 years ago
6 years ago

People

(Reporter: Jorge Martinez, Assigned: kinmoz)

Tracking

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [need info], URL)

(Reporter)

Description

17 years ago
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.
(Reporter)

Updated

17 years ago
Target Milestone: --- → M17

Comment 1

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

Comment 2

17 years ago
WFM Linux 091908. Anyone else verify?

Comment 3

17 years ago
Worksforme on Windows NT today with my debug build: 2000091312

Comment 4

17 years ago
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
Whiteboard: [need info]
Target Milestone: M17 → M19

Comment 5

17 years ago
Setting bug status to New.  Bugs whaich have been triaged to a target milestone
should not be Unconfirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

17 years ago
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

17 years ago
This bug has a confirmation

------- Additional Comments From sujay@netscape.com 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

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

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

Comment 9

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
moving to future, this needs to be reduced and tested before any recommendations
can be made
Target Milestone: M19 → Future

Comment 13

17 years ago
accepting to get rid of that annoying bugzilla reminder
Status: NEW → ASSIGNED
(Assignee)

Comment 14

17 years ago
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.
Assignee: beppe → kin
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla0.9.1

Comment 15

17 years ago
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!
Target Milestone: mozilla0.9.1 → Future

Comment 16

15 years ago
marking invalid.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID

Comment 17

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