280477 - homedepot.ca - select.options.remove rather than select.remove

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: English Other, defect)

Description

[zither99]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

on the store locator page @
http://www.homedepot.ca/escalate/store/ValidateInputs?pls=hd_canada_gift&validNextPage=content/static_StoreLocator
clicking the drop down menu's displays no information, it should be listing the
provinces and then after a province is selected the cities in that province.
Check using internet explorer for example.

Reproducible: Always

Comment 1

[Ben Fowler]

Attachment: Testcase

I am using a recent version of Camino, but I am seeing something very similar 
to what you describe

Your code has 71 markup errors in 898 lines.

I attach a testcase intended to be the same as your code, but without errors.

Note that this does not work for me, but does work inside BBEdit, so there is 
probably a definite reason for what your seeing - I don't know what reason is 
just yet.

Comment 2

[Phil Ringnalda (:philor)]

What do markup errors have to do with anything? It's a JavaScript error, using
IE's guess at what the HTML DOM Level 1 might have said about the options
collection on a select element, rather than what it wound up saying, if you want
to remove options do it on the select object.

Interestingly enough, not only could they switch their IE-DOM
sel.options.remove() to HTML DOM sel.remove(), they actually have Core DOM code
that we would like just fine, which they only offer to navigator.vendor ==
"Apple Computer, Inc." (which is probably why it works fine in BBEdit).

Comment 3

[Ben Fowler]

(In reply to comment #2)
> What do markup errors have to do with anything? 

      Why is validation a good filter? Because nobody makes valid
      pages by accident. If you come to us and say, Hey, I have this
      page, it’s valid XHTML and CSS, and I’m having this specific
      problem, well OK, you’ve obviously put some work into it,
      you’ve met us more than halfway, let’s see what we can do. But
      if you come to us and say, Hey, I slapped together this page
      and it works in X browser but now my client says it doesn’t
      work in W, Y, and Z, they must be buggy pieces of ****, well…
      you catch more flies with honey, and you get more help with
      valid markup.

http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you = An
example of a thing that markup errors have to do with.

OK, Bugzilla is not for user support, but at the outset, I can't be sure
that what looks like a user support level report doesn't in fact contain
information that might reveal a defect in Firefox. See Bug 275479 "Misalignment 
in 'ez publish' created website" where (arguably) I got it wrong.

I make it a practice to somehow fix all mark-up validation errors before
analysing a file in any way. Personally I wish reporters did this, but
then I wish that the world were perfect!

Comment 4

[Phil Ringnalda (:philor)]

Looks like Homey decided it was simpler to just list provinces, and then make you type a city instead of listing cities, so, problem disappeared.