272126 - Page doesn't render when refering with anchor, works without

Status: RESOLVED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[RobertJ]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

This page uses Javascript to process the #Standards anchor in the url.  For some
reason it fails to render in FF.  Note, it renders in IE and Safari.  The same
result occurs using Windows and Mac and if the HTML file and JS file are on a
server or are local.

Reproducible: Always
Steps to Reproduce:
1. go to http://www.standards.com/index.html#Standards
2.
3.

Actual Results:  
Won't render

Expected Results:  
Should render

Comment 1

[RobertJ]

Attachment: HTML page source

Comment 2

[RobertJ]

Attachment: Javascript file for source

Comment 3

[OstGote!]

Confirming with Mozilla 1.8a5 on WinNT4.

Comment 4

[RobertJ]

This was posted by the web page owner of http://www.standards.com/index.html in
MozillaZine Forums.

I now see what is happening that is different between IE and Firefox.

For example, using a URL of the form http://www.standards.com/index.html#XXX,
where XXX is any of the 41 values that I specify in my javascript, IE does what
I intended and takes the user to the correct page. Where XXX is "Standards" or
"Temporary" or "ThisandThat", the target document is actually index.html itself.

IE handles all 41 cases as I intended, however, for the three targets that are
actually in index.html, Firefox causes the script to be called a second time.
The code looks like it is running correctly each time, i.e., it
executes the following statement.

location.replace(URLList[locSearch]);

Somehow, the 2nd pass thru the script using Firefox is causing a problem for
those three cases. You can see the behavior by using IE and Firefox with the
links in http://www.standards.com/test-links-global.html

Comment 5

[Howard Kaikow]

Attachment: This is the test source.

The test source demonstrates the problem reported.

Comment 6

[Howard Kaikow]

The problem is even deeper.

Instead of using, say index.html?XXX, I tried going via  finder.html?XXX.
Same problem.

Firefox seems to be doing something odd with index.html.

I added tests with finder.html to the test file at my web site.

Comment 7

[Howard Kaikow]

Attachment: Here's the script that avoids the problem.

I have rewritten the javascript so it avoids the different behavior in Firefox.


This does not explain why Firefox behaved differently than IE or Safari.

Comment 8

[Howard Kaikow]

Attachment: Here's test source.

Comment 9

[Howard Kaikow]

Attachment: Latest script

I believe that the attached script can be used to see the difference between IE
and Firefox.

In line 83, if you replace

location.hash = flag;

with

location.replace(flag);

One can see the difference between IE and Firefox that I noticed in my original
posting.

Use the test source that I previously posted.

Comment 10

[Howard Kaikow]

Attachment: Describes different IIE and Firefox behavior.

The attached file shows how to demonstrate two differences in behavior between 
IE and Firefox.

One of the differences occurs only when using the files offline.
The other is the issue I originally raised.

Comment 11

[Gérard Talbot]

What this bugfile needs is a clear description and clear definition of the
problem (along with explicit actual and expected results) and one single
*_reduced_* testcase enlightening the problem. There is no need to create
several (7 so far) attachments or pdf files here. 

What is a Simplified Test Case, and How Do I Make One?
http://www.mozilla.org/newlayout/bugathon.html#testcase

A difference in rendering does not necessarly imply that there is a bug with FF;
often, other browsers have wrong implementation of specifications or the specs
or de facto standards (rfc) allow latitude or QA in other browsers are not as
advanced, systematic, continuous and thorough as in Mozilla and Firefox. A
difference in rendering might justify an investigation or a closer examination
but per se it does not mean much.

Also, if the problem is about a query, then the bugfile should be about such and
not about other DOM 0 attributes or methods (like fragment identifier rfc2396 -
hash - or replace()) or about relatively vs absolute href. One bugfile for one
single clearly delimited/defined bug.

Upload attachments sparingly and wisely. Most of us can view HTML source code
and javascript code from a provided URL. Use significant, useful, descriptive
words whenever possible: the summary is pretty much useless, actual and expected
results are repeating what was said in the summary, etc.

http://www.mozilla.org/quality/bug-writing-guidelines.html

----------

fragment identifiers are case-sensitive: #standards won't bring you to the
anchor name #Standards. You call toLowerCase() almost everywhere in your js
code. When I paste
http://www.standards.com/index.html#Standards
into Firefox and then press the go button, the referenced resource is loaded and
then url entry in the location bar is changed to
http://www.standards.com/index.html#standards
So the hash value is changed *after* loading the referenced resource and without
replacing the url in the history and location bar. replace() method is used to
replace in the history and in the location bar the current location with an url.

location.hash and location.replace() do distinct, separate tasks. It's not
immediately clear or obvious what your 5 levels of nested if..else are supposed
to do. Again, a reduced testcase...

---------------

On a side note,
- in your code, all 41 anchors are empty nodes, empty anchors: that is not best
- you use <blockquote> to indent listable text, non-quoted text or section of text
- it's possible to call the toLowerCase() method in a array member when
populating an array but certainly not recommendable. Why resort to
URLList["AreasBug".toLowerCase()] = ...;
when
URLList["areasbug"] = ...;  will do?

My 2 cents

Comment 12

[Boris Zbarsky [:bzbarsky]]

So... as far as I can tell the page was modified somehow?  Certainly the
testcase in comment 4 indicates that it was modified to not show the problem.

That makes it very difficult to figure out what the problem is.  So could
someone point me to a page clearly showing the problem?

Comment 13

[Boris Zbarsky [:bzbarsky]]

No response, no way to reproduce, marking invalid.  Please reopen if there is a
way to reproduce the problem.