332224 - targetFrame.document.getElementById.className="nonSelectable" had no effect

Status: VERIFIED INVALID

(Firefox :: General, defect)

Description

[Jean-Pierre Dehottay]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv 1.8.0.1) Gecko/20060124; Firefox/1.5.0.1

Problem encountered with executing the following JavaScript code within "srcFrame"

dstFrame.document.getElementById(dstId).className = "nonSelectable";

"dstFrame" is an <iframe> within "srcFrame".document.
"srcFrame" and "debugFrame" are neighbour <frame>s within a <frameset>.
"dstId" is associated to a <table> whose <tr>s are made "selectable" or "nonSelectable".
"dstId" of course is unique within "dstFrame".document (checked!).

Execution success confirmed by debug output from a JavaScript routine, containing the line above, into a "dbgFrame". But: on the window, the rows unfortunately remain selectable!

A little hope: that the browser implementors one day will have time enough to offer us a document pretty-printer displaying a source out of the document most recent abstract syntax tree.
The effect of e.g. "document.replaceChild()" is perfectly visible on the screen, but not in the source given by the "View page source" menu entry.

Thanks in advance,
jpd (Berlin, Germany)

Reproducible: Always

Steps to Reproduce:
1. Display a <table> in an <iframe> of <frame> "dstFrame"
2. Execute, in a JavaScript routine sent to "srcFrame", the code shown in "Details"


Expected Results:  
The browser should not allow for selection of <tr>s within the <table> (the "onMouseOver" event associated with the <tr>s checks for the <table>'s class).

The problem arised at transition, in my software, from a stage of full frame or iframe document redisplay to a stage redisplaying increments only, using DOM 1.0 JavaScript routine calls.

In this new model, the HTML increments are sent to a frame together with an automatically generated JavaScript routine implanting the increments into the document. 

Everything works perfectly, with the exception of the little problem described above.

Comment 1

[Philip Withnall (unavailable)]

Can you attach a webpage demonstrating this please?

Comment 2

[Jesse Ruderman]

> But: on the window, the rows unfortunately remain selectable!

Why do you expect setting an element's className to "nonSelectable" to make it non-selectable?  Is there a stylesheet in the correct frame with something like ".nonSelectable { -moz-user-select: none; }"?

It would help if you could attach a small testcase, or at least give us the URL of a page demonstrating the problem.

> A little hope: that the browser implementors one day will have time enough to
> offer us a document pretty-printer displaying a source out of the document 
> most recent abstract syntax tree.

Select some stuff and use "View Selection Source" on the context menu, or use DOM Inspector (usually in Firefox's Tools menu), or use the "generated source" bookmarklet from http://www.squarefree.com/bookmarklets/webdevel.html.

Comment 3

[Jean-Pierre Dehottay]

Bonjour,

I must apologize for having created this bug entry at a time I began to no longer understand anything in my software, though pretty good knowing it would be impossible for DOM 1.0 routines to fail!

During development I overwrote, without noticing that, a little piece of code replacing

function onClickOnRow(rowId) {
	if (! document.getElementById(rowId) == "selectable")
		return;
...

by  the code

function onClickOnRow(rowId) {
	if (! (document.getElementById(rowId) == "selectable"))
		return;
...

I just had tested successfully before.

And thus, since I was sure the increment to be right, I had no look at it at run time during more than one week, got more and more crazy and... "Verzweiflung ist kein guter Ratgeber", they use to say here. I could reproduce the old stage today, and the error was back.

Mea culpa! Please drop this truly useless entry off the list!

Apart from that, it was nice to see how simple it is to modify HTML documents within the browser without full redisplay, without asynchronous background, without XML, by simply sending HTML increments together with little JavaScripts to a zero size frame, and upon load, to execute them. And it was amazing to see, of course without having known before that it would really do so, the Mozilla browser perfectly and quickly inserting, replacing or removing increments within the document and any of its subframes or neighbour frames! Terrible.

But as good it is to develop such an idea out of one's own, without any kind of contact to anybody's experience even on the net, as ugly it is to stay proud in one's provincial corner. May be you know of people having made the same experience mlonger time ago? I couldn't find anyone, but Google only can search for what you tell him...

Regards,
jpd

Comment 4

[Jesse Ruderman]

> Apart from that, it was nice to see how simple it is to modify HTML documents
> within the browser without full redisplay, without asynchronous background,
> without XML, by simply sending HTML increments together with little JavaScripts
> to a zero size frame, and upon load, to execute them.

I think you can get a similar effect with http://www.squarefree.com/bookmarklets/webdevel.html#jsenv.