Closed Bug 12679 Opened 21 years ago Closed 21 years ago

Bugzilla new bug submit does nothing

Categories

(Core :: DOM: Core & HTML, defect, P1, blocker)

x86
Linux
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: mcafee, Assigned: akkzilla)

References

Details

Linux, apprunner.
I type all this stuff in for a new bug
and hit submit, the page just sits there
and does nothing.!
Assignee: karnaze → kmcclusk
Reassigning to Kevin.
QA Contact: cpratt
Summary: Bugzilla new bug submit does nothing
testing to see if an update works... I do notice that the summary field, QA
contact etc. show up blank
QA Contact: cpratt
Summary: Bugzilla new bug submit does nothing
Nice, it blanked out the summary and QA contact, but at least I could update it.
Looks like our builds are from 7am. When did you pull.
Status: NEW → ASSIGNED
Assignee: kmcclusk → pollmann
Status: ASSIGNED → NEW
Eric, reassigning to you. Please check the post data from mozilla against the
post data generated from communicator. If different, reassign back to me.
Status: NEW → ASSIGNED
Blanking out of the summary and QA contact is bug 12475.
What happens when you click Submit?  Does the entire AppRunner application
freeze, or is it still responsive and just not submitting forms?  I was able to
reproduce a complete freeze just now...
Assignee: pollmann → buster
Status: ASSIGNED → NEW
I reproduced this by:
1) Go to bugzilla
2) Enter new bug report
3) Browser
4) Assign to pollmann@netscape.com
5) Summary=test
6) Commit

It's infinite looping in nsHTMLToTXTSinkStream::WriteWrapped()
I noticed mWrapColumn is 0, which seems to be causing the infinite loop.

This is happening when the GFX Text frames are trying to get their text to
submit the form.

This is the stack up to relevant point:
nsHTMLToTXTSinkStream::WriteWrapped
nsHTMLToTXTSinkStream::AddLeaf
nsXIFDTD::AddLeaf
nsXIFDTD::HandleTextToken
XIFDispatchTokenHandler
CTokenHandler::operator()
nsXIFDTD::HandleToken
nsXIFDTD::BuildModel
nsParser::BuildModel
nsParser::ResumeParse
nsParser::Parse
nsTextEncoder::EncodeToString
nsHTMLEditor::OutputToString
nsGfxTextControlFrame::GetTextControlFrameState
nsGfxTextControlFrame::GetProperty
nsHTMLTextAreaElement::GetValue
nsGfxTextControlFrame::GetText
nsGfxTextControlFrame::GetNamesValues
nsFormFrame::ProcessAsURLEncoded
nsFormFrame::OnSubmit
Assignee: buster → akkana
akkana:  looks like you're on top of the stack. If I'm somehow misusing the
wrapping API, let me know and I'll fix my code.
Status: NEW → ASSIGNED
Target Milestone: M10
I'll take a look.  Even if you are somehow using the API in an unusual way, if
that somehow causes an infinite loop then that's a bug that needs fixing.
Depends on: 12808
I can't reproduce or work on this on Linux, because clicking in any gfx-rendered
text field produces an immediate crash in nsBlockFrame::HandleEvent.

I've filed bug 12808 on that issue, and will meanwhile be looking over the code
to see if I can see possible infinite loops just by inspection, and I'll update
my tree on Windows in the meantime and see if I can reproduce it there.
Severity: normal → blocker
Priority: P3 → P1
Another test: go to http://bugzilla.mozilla.org/,
type in a bug number, hit find.  Nothing happens.
submit is still broken for non-gfx widget mode as well.
Is this Linux only?
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
This seems to be working now, for gfx widgets.  Not sure about non-gfx widgets,
but that would be a different bug in any case.
Status: RESOLVED → VERIFIED
Trusting akkana and verifying.
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.