search.php produces non valid html

VERIFIED FIXED

Status

VERIFIED FIXED
13 years ago
3 years ago

People

(Reporter: cameron, Assigned: clouserw)

Tracking

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
<input type="hidden" name="app" value="firefox"/> has to be inside a <div> (or something else) inside <form>
(Reporter)

Updated

13 years ago
Blocks: 332987

Comment 1

13 years ago
I don't understand.  form is a block level item and input is an inline item.  Why would it have to be inside of the div?  I just noticed that this line is in there twice.  Could that do it?

# <div class="key-point">
#
# <form action="/search.php" method="get" class="amo-form">
# <input type="hidden" name="app" value="firefox"/>
#
# <div>

# <!-- end search-options -->
# </div>
#
# <input type="hidden" name="app" value="firefox"/>
# </form>

Comment 2

13 years ago
Do we even need this hidden field?  search has <select id="appfilter" name="appfilter"> which will have a value of whatever we're trying to show.
(Assignee)

Comment 3

13 years ago
Created attachment 217657 [details] [diff] [review]
Moves the <input>s inside a <div>

In the HTML 4.01 specs they always have another block level element inside the form tag.  It's weird tidy doesn't catch this though (in the html validator extension).  Anyway, here is a patch that fixes it, and it's in cvs now.
Assignee: morgamic → clouserw
Status: NEW → ASSIGNED
(Assignee)

Updated

13 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
(Reporter)

Updated

13 years ago
Status: RESOLVED → VERIFIED
Target Milestone: 2.1 → ---
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.