284656 - JavaScript window.open failure after innerHTML modification on Firefox

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Michael Han]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

1. Click on the text in test.htm opens win.htm.
2. win.htm modifies the text in test.htm via getElementById.innerHTML.
3. Once you close win.htm you can't reopen it using the modified version of text
in test.htm.

This behavior seems to be illogical, therefore I consider it to be a bug. The
behavior seems to be more logical on Internet Explorer.

Reproducible: Always

Steps to Reproduce:
1. open URL
2. click on the text
3. close the new window
4. click on the modified text again to open the window once more

Actual Results:  
The window doesn't open for some reason. The behavior seems to be a bug.

Expected Results:  
It should've opened the window again.

Comment 1

[Ben Fowler]

Please review Bug 282573 "Element created in a page from popup can't open popup"

If you want logical behaviour, try using DOM techniques.

Comment 2

[Michael Han]

(In reply to comment #1)
> Please review Bug 282573 "Element created in a page from popup can't open popup"
> 
> If you want logical behaviour, try using DOM techniques.

Two files from the URL, test.htm and win.htm, were created to point out the
underlying problem, so they don't include some information which I considered to
be irrelevant to the problem at hand. However, I am more ignorant of DOM
standards an techniques than many of developers out there, so I'm willing to learn.

According to WCAG 2.0 reference from W3C use of innerHTML or document.write()
seems to have deprecated for accessbility feature. Here's the quote from
http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-SCRIPT-TECHS-20041008/Overview.html:

"Additionally, document.write() and innerHTML() can render content invalid after
the fact, which presents problems for those assistive technologies that do
support script."

Is Firefox giving higher precedence to aforementioned rule when it processes
innerHTML? I'm just pondering. If not, then why does it invalidate the newly
modified string?

I still haven't been able to figure out what 

Comment 3

[Michael Han]

(continuing from last comment; please ignore the last line of the last post, "I
still haven't figured out what")

Maurizio Merli said "the BUG is in window.open in element created with
innerHTML" from Bug #282573, and I have to agree with him. There seems to be
practically zero standards reference on W3C DOM-related links. Did innerHTML
originate with IE? Is that why Mozilla is reluctant to fully adopt it? I do
agree that such feature has the potential to perturb the minds of those who form
standards, since it could easily rearrange any document object models. I guess
it has more to do with the issue of precedence. I say give more power to
innerHTML. :)

Comment 4

[Michael Han]

After reading through more issues on innerHTML vs. DOM, I've come to realize
that I've joined the beating of horse that isn't willing to die, but I think
it'd be wise to accept what is more practical and useful to the programmers. But
my question remains. If Mozilla team decided to include innerHTML, however
reluctantly, why do it only half-heartedly? You either include it or you don't.
Such half-hearted inclusion may do good to the cause of DOM standards and
eradication of IE-originated tags, but ultimately, it becomes a poor example of
software engineering, and even ethics if there is one.

Comment 5

[Ben Fowler]

I agree that making the leap from where you are now in understanding Mozilla's
implementation of DOM 0, and where you want to be is a crucial step, but it would 
not seem to me to part of Bugzilla's missions.

If you think that the implementation of innerHTML is incomplete and/or should 
be extended, please find the relevant bug.

If you think that the documentation is incomplete, confusing or has gone 
missing, please go through those channels.

This report is probably WORKSFORME.

Comment 6

[Michael Han]

Ben,

Thanks for your time and dedication in this forum. I really appreciate your
sincere effort here. I lack the depth of understanding of DOM to make a
commitment to it yet, but that crucial step would be made eventually--in
whatever direction that may be. Just as I miss the ol' GOTO statement of BASIC
era, I'd hate to see this innerHTML disappear. I'm one of those few who still
haven't made the full transition to this Bjarne Stroustrup's era; a dinosaur who
still cooks spaghetti codes with a knack for high-level optimization. :) Good day.