Form doesn't show submit button: regression from 1.0.6 to DPalpha2

RESOLVED FIXED in mozilla1.8beta4

Status

()

--
major
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: wolruf, Assigned: mrbkap)

Tracking

({regression, testcase})

Trunk
mozilla1.8beta4
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
Build ID: FF Deer Park Alpha 2, 20050712 on WinXP.

Steps to reproduce:
1. Load testcase with DPa2, no submit button shows up,
2. Load testcase with FF 1.0.6 or IE6, submit button shows up.

If I remove the <p>, the <textarea> or the <a> tag, the submit button shows up
in DPa2.
(Reporter)

Comment 1

14 years ago
Created attachment 189870 [details]
Testcase (doesn't show submit button on Deer Park alpha 2)
(Reporter)

Comment 2

14 years ago
Created attachment 189874 [details]
Working testcase (removed <p> tag)
This regressed between 2005-06-01-07 and 2005-06-02-07.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-01+07%3A00&maxdate=2005-06-02+07%3A00&cvsroot=%2Fcvsroot
This seems to be an HTML parsing issue. unfortunately, the regression window
contains quite a few parser patches.

Updated

14 years ago
Severity: normal → major

Updated

14 years ago
Assignee: nobody → parser
Component: General → HTML: Parser
Product: Firefox → Core
QA Contact: general → mrbkap
Version: unspecified → Trunk
(Reporter)

Comment 4

14 years ago
Camino 0.9a2 is also (logically) affected.
OS: Windows XP → All
(Assignee)

Comment 5

14 years ago
Taking, this looks like another bug resulting from the move away from skipped
content.
Assignee: parser → mrbkap
(Assignee)

Comment 6

14 years ago
Created attachment 189938 [details] [diff] [review]
patch v1

I'm not entirely sure why the <p> was needed here, but this patch is correct.
The problem is that the <a> is being closed by the <p> and reopened inside the
<textarea>, so we were ignoring the <textarea>'s end tag and putting the rest
of the document into the textarea. With this patch, we don't allow residual
styles to be opened inside the textarea and things are happy.
Attachment #189938 - Flags: superreview?(jst)
Attachment #189938 - Flags: review?(jst)
(Assignee)

Updated

14 years ago
Status: NEW → ASSIGNED
Comment on attachment 189938 [details] [diff] [review]
patch v1

r+sr=jst
Attachment #189938 - Flags: superreview?(jst)
Attachment #189938 - Flags: superreview+
Attachment #189938 - Flags: review?(jst)
Attachment #189938 - Flags: review+
(Assignee)

Comment 8

14 years ago
Comment on attachment 189938 [details] [diff] [review]
patch v1

This patch is very safe and prevents a silly regression where textareas would
eat up the rest of the page if there were any residual style tags (such as <a>)
on the residual style stack.
Attachment #189938 - Flags: approval1.8b4?
(Assignee)

Comment 9

14 years ago
For the record: the <p> is necessary because <a> can contain <textarea>, so it
wasn't getting put on the residual style stack. I suspect if there was a space
or text before the <textarea>, this problem would have been masked. So the
reduced testcase is:
<a><p><textarea></textarea>hi

Updated

14 years ago
Attachment #189938 - Flags: approval1.8b4? → approval1.8b4+
(Assignee)

Comment 10

14 years ago
Fix checked in. Thanks for finding this.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Assignee)

Updated

14 years ago
Target Milestone: --- → mozilla1.8beta4
You need to log in before you can comment on or make changes to this bug.