Closed Bug 354119 Opened 18 years ago Closed 18 years ago

event handlers are not resolved when assigned to, unqualified (in with statements)

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID
Milestone:
mozilla1.9alpha1

People

(Reporter: mscam_de, Unassigned)

References

(
URL
)

Details

(Whiteboard: [should be fixed in 159849]) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

To test this error, which make my site unusable with FireFox, go onto the above address and click the link: FireFox Test.
On this page the variable-monitoring is activated, so you can see, how a variable is being lost.
(Otherwise it is the same as "Georg's First communion")

These Picture-Gallery pages work in my standard Browser "Maxthon".

This is the first of many errors in Firefox!.
Please compare the site as displayed by Firefox and Maxthon.

I expect a reply within 24 hours. I know, that you may not be able to repair the serious errors in your browser within this time, but I see no reason for not confirming the error, or if you discover, that the cause is a known incompatibility between the IE interpretation of Javascript and that of FireFox, information of the necessary workarounds.

Yours Sincerely
M.S.C.A.M. de Rakovszky
Rako DP Enterprises

Reproducible: Always

Steps to Reproduce:
1.Load http://www.rakovszky.info
2.Click on the FireFox Test link
3.Observe the information about the monitored global variables.

Actual Results:  
Data stored in global variables is lost

Expected Results:  
See how it works using Maxthon

If you need, I can send you a copy of the Javascript libraries, after receiving an assurance, that they will be used only for Firefox testing, and will not be given to anyone outside the testing group, and after the tests, it will be deleted from your files.
These libraries and pages are copyright.
Unless you're willing to provide more information as to what exactly isn't broken, or can provide a smaller testcase than "click the link on my site and view a series of popups that display cryptic looking variable names and values", there isn't likely to be any progress on fixing this bug.

Ideally, a minimized testcase that shows exactly how Maxthon and Firefox differ would be attached to the bug.
There is no way to provide an easier test case.
I am willing to send you the javascript source code.

The first part of the message identifies the page which generates the message. This is followed by the Javascript function-name and an identifier of the message within the function. This is followed by the names and values of the variables that are monitored at that point.
Please look carefully at the value of "CurrPosit". At one point it has the correct value, next it is undefined.

It is a complex system, where the contents of the iframe are loaded into a standard frame containing the logo and control routines.

Each of the functions in question, as far as this bug is concerned is simple.

The names of the pictures to be displayed are in a control file. From this a table is generated, where thumbs are displayed.
If you click on a thumb, that picture should be displayed in the main area.
On loading, the first picture should be displayed (Check with Maxthon to see how it should look like). FireFox does not load it.
Look at the backgroung of the thumbs when you move the mouse-pointer over them. It should change. (See in Maxthon). With Firefox it ignores the mouse-movements.
When cliking on the arrow below the smilie next to the Thumbs, the next picture should be displayed. After the first picture, an arrow appears above the smilie. Clicking that arrow goes to the previous picture.

The functions are:
function ArrowClick(TrNr) {
if (MonitorMe)
   alert (WhoAmIText+"  ArrowClick-0  TrNr="+TrNr+"  CurrPosit="+CurrPosit);
  	TblRows[CurrPosit].style.backgroundColor = SavedBGColour;
  	var NextPict = CurrPosit + TrNr;
if (MonitorMe)
	alert (WhoAmIText+"  ArrowClick-1  NextPict="+NextPict);
	ThumbClick(NextPict);
} //  --------------  end of function ArrowClick

Monitor me is set in the initialisation routine, so that only the selected pages are monitored.
TrNr can have the value +1 or -1 to go to the next or previous picture.

	
function ThumbClick(TrNr) {
if (MonitorMe)
	alert (WhoAmIText+"  ThumbClick-0  TrNr="+TrNr+"  CurrPosit="+CurrPosit);
   	CurrPosit = TrNr;
   	SavedBGColour = TDShownColour;
   	TblRows[CurrPosit].style.backgroundColor = TDCurrSelColour;
   	var ListIdx = CurrPosit + FirstNamePtr-1;
   	var ImgSrc =  CurrArray[ListIdx];
   	var CopyrightText;
   	var CurrLng;
   	var ShowArrow = "visible";
	Ptr = ImgSrc.indexOf("µ") ;
	if (Ptr == -1)
		CurrTitleText="";
	else {
		Temp = ImgSrc;
		TxtLg = Temp.length;
		ImgSrc = Temp.substring(0, Ptr);
		CurrTitleText = Temp.substring( Ptr+1, TxtLg);
	}  //  if (Ptr == -1)
	Ptr = ImgSrc.indexOf("©") ;
	if (Ptr == -1)
		CopyrightText="";
	else {
		Temp = ImgSrc;
		TxtLg = Temp.length;
		ImgSrc = Temp.substring(0, Ptr);
		CopyrightText = Temp.substring( Ptr, TxtLg);
	}  //  if (Ptr == -1)
	
   	ImgSrc = CompleteFileName(ImgSrc, WantPictName);
	document.getElementById(TargetImage).alt=ImgSrc;
	ImgSrc = CurrFolderPrefix + CurrFullPictFolder + ImgSrc;
	document.getElementById(TargetImage).src=ImgSrc;
//	alert ("ThumbClick 1  ImgSrc="+ImgSrc+"    Temp="+Temp+"   CurrTitleText="+CurrTitleText);
	if (CurrTitleText != "") {
		CurrTitleText = GetLangTxt(CurrTitleText,LanguageIndex);
	}
	Temp=CurrInfoArray[8];
	CurrLng = document.getElementById(Temp).firstChild.nodeValue.length;
	document.getElementById(Temp).firstChild.replaceData(0, CurrLng, CurrTitleText);
	Temp=CurrInfoArray[11];
	CurrLng = document.getElementById(Temp).firstChild.nodeValue.length;
	document.getElementById(Temp).firstChild.replaceData(0, CurrLng, CopyrightText);
	if (CurrPosit < 2) 
		ShowArrow="hidden";
	else
		ShowArrow="visible";
	document.getElementById(ToFirstPictArrow).style.visibility = ShowArrow;
	document.getElementById(BackArrow).style.visibility = ShowArrow;
	if (CurrPosit < LastThumbNr) 
		ShowArrow="visible";
	else
		ShowArrow="hidden";
//	alert ("ThumbClick 2      TblRowPos[CurrPosit]="+TblRowPos[CurrPosit] );
	document.getElementById(NextArrow).style.visibility = ShowArrow;
	document.getElementById(ToLastPictArrow).style.visibility = ShowArrow;
    document.getElementById(TblContainerId).scrollTop=TblRowPos[CurrPosit];
	
} //  --------------  end of function ThumbClick

If you have any difficuties to debug your browser, you can send me a debugging programm, with which I can monitor exactly when and why does the value of CurrPosit gets lost.

As it works perfectly with Maxthon (and this part with Opera as well) it must be an inherent error in the logic of FireFox or the Mozilla core.

Could it be, that Firefox is unable to handle correctly multiple javascript libraries, or such that exceed a certain size? Or it has some difficulty when the number of global variables or simply variables exceeds a certain limit?




The code on this page seems to have a fundamental misunderstanding of either |with| or |this|.  Furthermore, it uses .rowIndex, which gavin and I aren't sure is standard.  The relevant snippet is...

var TR = document.getElementById(ThumbsTableId).insertRow(Zeile);
...
with (TR) {
	onclick = function() {ThumbClick(this.rowIndex );};  // ThumbClick(rowIndex);
	onmouseover = function() {ChangeBGC(this.rowIndex,1);};
	onmouseout = function() {ChangeBGC(this.rowIndex,0);};
	appendChild(TD1);
}  //  end with

However, the use of this.rowIndex is inappropriate in the with block.  For example:
js> var foo = { bar: 1 };
js> function baz() { with(foo) { print(this.bar); }}
js> baz();
typein:13: strict warning: reference to undefined property this.bar
undefined

Using |with| does not change the value of |this|.

Suggest Resolved: Invalid.
Rowindex IS standard.
If you are not sure, please check your statements.
As you have made in this such a caipal error, I suspect, that your comment about the "with" and "this" is just as mistaken. 
In my documentation about all these it states clearly that they are standard both in IE and in Netscape/Firefox.

AND: it works correctly with IE. Thus if it does not work with Firefox/Netscape, both of them contain a very serious error and should be withdrawn until it is corrected.

I know what I am talking about. I have 44 years of experience in software development, which ranges from microcode to mainframe operating systems.

If Firefox does not support standard Javascript, then it is useless. I do not think, that you want to hear this, so please check your information again.
Unluckily I cannot quote the documentation in English, as I have it only in German, but if you want it, you can check  on the pages of "http://aktuell.de.selfhtml.org/" Perhaps you can find the original English texts too.

jminta: the code you mentioned is ok actually. |with| indeed doesn't affect the value of |this|, but when a handler function is invoked, |this| is bound to the object it's a handler on.

Reporter: with 44 years of development experience you should be able to construct more or less minimal standalone testcase (that can be attached here). The bug most likely won't be fixed until someone creates a minimal testcase, and I expect that most people don't want to dig into your site's code, because it's likely that the bug is actually in your code. Unless you're a JS/DOM guru, it's easy to fall into one of JS traps.
Severity: critical → normal
You are right, I may be able to construct a minimal test case, but I just do not have the time for it.
I have already lost too much time because of the idiosyncracies of Firefox.
My project is not the development of javascript (it is just a necessary evil), but historical research.
As I suspect, the error is caused by the size of the script, (at an earlier stage it did not lose the information, but as the project progressed and some, for this case irrelevant code came into it, suddenly it began to lose the information.

The variable CurrPosit is initialised to 0 when declared, reset to 0 when the table is created, and set to the new value in the function ThumbClick.
The ThumbClick is called either through a mouse-click on the Thumb-image, when the row-number is passed as parameter, or through the function ArrowClick.
ArrowClick receives as parameter either +1 or -1.
It accesses the previously set value of CurrPosit, which was set to a correct value previously, but is now undefined.
PLEASE EXPLAIN THIS.
I do not have the testing capabilities/tools/time to analyse the source code of FireFox/Mozilla to find out when and how this global variable gets destroyed.
I suspect, that it is destroyed by your code in one of the following lines:
in function ArrowClick:
  	TblRows[CurrPosit].style.backgroundColor = SavedBGColour;
  	var NextPict = CurrPosit + TrNr;

in function ThumbClick:
   	TblRows[CurrPosit].style.backgroundColor = TDCurrSelColour;
or
	if (CurrPosit < 2) 
or
	if (CurrPosit < LastThumbNr) 
or 
    document.getElementById(TblContainerId).scrollTop=TblRowPos[CurrPosit];


These are the only references to this variable.

There is another possibility: the javascript is read into a buffer. If it is too small, there is either an overflow, or the code presently stored in it will be overwritten, and called back when required again. But the variables in it are destroyed by this action.

These are things you can investigate yourself with line by line monitoring the execution of these routines.
(at least I assume, that you have such a testing aid.)

I would like to ask you to tell me, where can I find a Mozilla javascript code verifier that works. My verifiers pass the code as perfectly legitimate. Including the built-in debugger of the Internet Explorer and Adobe's GoLive. (I do not allow GoLive to generate code because it is extravagant, but use its editor, reference-handling and FTP functions only.)
> jminta: the code you mentioned is ok actually.

Actually it's not ok, sorry. It causes a strict warning about assigning to undefined variable 'onmouseout', because there's no property 'onmouseout' on the element by default. Since this is DOM 0, I'm not sure how it's supposed to work, but it's something you could easily figure out yourself if you had strict JS warnings enabled (javascript.options.strict -> true in about:config).
Yet another example of incompetence: onMouseOut is an official Javascript function and not a variable.
No wonder that Firefox does not work, if the developers or testers have no idea what should work.
Anyway, the onMouseOut function has nothing to do with the global variable CurrPosit becommming suddenly undefined.
That Firefox cannot handle the Javascript functions of onMouseOver and onMouseOut is another error that will have to be resolved, but after the top priority bug have been corrected.
The absence of the backgound colour-change just shows, that FireFox is lame, but does not prevent the user from seeing the picture he wants.
(I am no Microsoft fan, but IE and its derivatives work, some better than others, while Firefox does not, and that is my concern: I want ot make certain, that Firefox users can access my site.)
> Yet another example of incompetence: onMouseOut is an official Javascript
> function and not a variable.

No,
1) onmouseout is not "an official Javascript function". It's a property you can set to your own function to listen to events.
2) Apparently you don't know how |with| works, so just don't use it.

I happen to know how with works. I have been using it for years now.

As for the onMouse functions: some interpreters may require, that it is prefixed in the html code with javascript, some do not.
It is a small thing to correct, if that is the only reason that the mouse-movement is not recognised. 

But the main bug is the lost global variable. Until that is solved, I do not want to waste much time with the others. First thing first.
If the high priority bug is not corrected, there is no point to spend more time to correct other minor faults/misunderstanding in my code.



please try the following code:
<html><head><title>Test</title>
</head><body>
<a href="http://aktuell.de.selfhtml.org/news.htm"
onmouseout="alert('Die News sollten Sie ruhig mal besuchen')"><b>News</b></a>
</body></html>

you will see, that in this case the "onmouseout" functions ok.

Please check your statements for validity before such claims like your about this function.
I'm sorry, but you're totally confused. I was correct about onmouseover, it's a DOM property / attribute, not an 'official Javascript function'. I haven't ever said anything about prefixing your code in onmouseover-like attributes with 'javascript:' (doing so is wrong by the way).

Regarding |with|, I think you don't really know about the issue you tripped over. (See http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Statements:with#Description Ambiguity Con.) When you do:
 with (TR) {
   onclick = function() {...}
 }

You get the strict warning because there's no 'onclick' property on TR that you intend to assign to yet, so, due to the way |with| works, the function gets assigned to the global variable named 'onclick'. Since you never defined that variable, you get the strict warning.

This bug is invalid without a minimized testcase, since you may well have a few other errors like this causing vars to get 'lost'.

I think I've got a minimal testcase here: http://pantheon.yale.edu/~jpm76/with-this2.html

In IE you get 'bar', in Firefox you get 'undefined'.
That looks like a bug in event handler invocation code.  The js shell test works:

js> function startup() {
  var button = document.getElementById("mybutton");
  button.foo = "bar";
  with(button) {
    onclick = function() { alert(this.foo); };
  }
}
js> theButton = {onclick:null}
[object Object]
js> document = {getElementById: function(){return theButton}}
[object Object]
js> startup()
js> uneval(theButton)
({onclick:(function () {alert(this.foo);}), foo:"bar"})
js> alert = print
function print() {
    [native code]
}
js> theButton.onclick()
bar

/be
Assignee: nobody → events
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
Adding some alerts shows that the bug is what Nickolay said in comment 12, but it is a bug in Mozilla's DOM code.

Reporter, thanks for reporting this.  It will be fixed in Firefox 3.  In the mean time, avoid with statements to work around the bug.

/be
Status: UNCONFIRMED → NEW
Component: DOM: Events → General
Ever confirmed: true
Product: Core → Firefox
Version: 1.8 Branch → 1.0 Branch
Component: General → DOM: Level 0
OS: Windows 2000 → All
Product: Firefox → Core
Hardware: PC → All
Target Milestone: --- → mozilla1.9alpha
Version: 1.0 Branch → Trunk
Summary: FireFox loses information stored in global variables/function-call parameters → event handlers are not resolved when assigned to, unqualified (in with statements)
The bug is clear from the comment at http://lxr.mozilla.org/mozilla/source/dom/src/base/nsDOMClassInfo.cpp#7119 and the code it decorates.  In a with statement, NewResolve is the only API that will be called, and if it does not define the sought-after "onclick" or equivalent event handler property, then the SetProperty API hook will never be called and the scope chain search will end up at the global object, where onclick will be bound.

This is easy to patch; I'll leave it to a DOM owner or peer to do.

/be
Assignee: events → general
Flags: blocking1.9?
Re comment #12:
1.) I never said, that you suggeste the "javascript" prefix.
Some documentation codes it as "javascript'onMouth......'" (free quote, the actual sintax is here irrelevant)
2.) I am not confused, and I take exception to your remark.
The exact description, whether an "official Javascript function" or " a
DOM property / attribute," is irrelevant in the context. It was a reply to someone saying it is an "undefined variable", which it is not.

I am not a Firefox tester, so these bugs just steal my time. 
I do not even use Firefox, but have to make certain, that FireFox users can display my pages. At the present due to the bugs in Firefox, they cannot!!!

This "onMouse..." issue seems to be confirmed, but the main bug, that if the lost global variable is not.
As this prevents the proper display of a large number of my pages, and seems to be connected to the size or complexity or structure of the pages (multiple javascript libraries, etc) it must be found and corrected quickly. Until it is found, we cannot know, whether in other cases it shows up in different form, or what other things may be corrupted. Perhaps there may be a security issue too.
The cause of the lost information must be found quickly.
(In reply to comment #17)
> This "onMouse..." issue seems to be confirmed, but the main bug, that if the
> lost global variable is not.
This is not true at all.  My testcase shows exactly how this variable gets 'lost'.  If you pay close attention to the code, you'll notice that your TrNr variable is the first to become 'undefined'.  This is due to the combination mentioned previously of |with| and |this|.  Then, later, you're going to try to assign to CurrPosit from TrNr.  Specifically, you do:
function ThumbClick(TrNr) {
if (MonitorMe)
	alert (WhoAmIText+"  ThumbClick-0  TrNr="+TrNr+"  CurrPosit="+CurrPosit);
   	CurrPosit = TrNr;

Since TrNr is undefined, of course CurrPosit becomes undefined the next time you use it.  To repeat, this is caused by the fact that |this| in your event handlers does not get resolved, because you used |with| too.  That is what this bug describes and that is what is causing your variable to seem lost.  Lose the attitude.

If the new summary is what this bug is about now then it's a dupe of bug 159849.
Comment #13
The two cases are not the same:
CurrPosit is a simple global variable, which loses its contents/definition.
I have modified the function ArrowClick a bit.
function ArrowClick(TrNr) {
if (MonitorMe)
   alert (WhoAmIText+"  ArrowClick-0  TrNr="+TrNr+"  CurrPosit="+CurrPosit);
  	var NextPict = CurrPosit + TrNr;
if (MonitorMe)
	alert (WhoAmIText+"  ArrowClick-1  NextPict="+NextPict+"  CurrPosit="+CurrPosit);
  	TblRows[CurrPosit].style.backgroundColor = SavedBGColour;
if (MonitorMe)
	alert (WhoAmIText+"  ArrowClick-2  NextPict="+NextPict+"  CurrPosit="+CurrPosit);
	ThumbClick(NextPict);
} //  --------------  end of function ArrowClick
When you click on the NextPicture arrow, the value of CurrPosit is valid
With FireFox only the first alert is displayed, and the parameter handed over to the next function (function ThumbClick(TrNr) ) is undefined.
In IE/Maxthon/Opera it works fine.
Here there is no with or this etc.
The setting of a simple locally defined variable is not being carried out properly
#19: it is not the same bug. If the bug is known since 2002, why has it not been corrected till now? Is FireFox a serious browser or a toy of a number of people, who can insert erros into it, so that someone can make use of it, or between the lot of minders the correction of diagnosed bugs may be forgotten!

#18: If YOU pay ANY attention to the code, you WILL have to notice, that what you write is utter rubbish.

Have a look at the code in #20
On entering the function ArrowClick, the variable CurrPosit is correctly set and TrNr = 1.
This is shown by the alert "ArrowClick-0"
The next instruction after this Alert is 
  	var NextPict = CurrPosit + TrNr;

Alert "ArrowClick-1" and Alert "ArrowClick-2" are not displayed as they should be.
Only the alert "ThumbClick-0", showing that TrNr, the parameter handed over by ArrowClick is not defined.

This is what you guys should investigate, quickly and thoroughly.

Previously, before the conditional alerts were inserted, the parameter was correctly handed over. Now it is clear that in the newest version (modified for the sake of testing ease) it happens a step or two earlier.

If the  alert "ArrowClick-1" were displayed but alert "ArrowClick-2" not, you could claim that it has something to do with the instruction
  	TblRows[CurrPosit].style.backgroundColor = SavedBGColour;
but it happens earlier!!!
I expect you testers have access to the source code with all the development environment, so that tracing what happens within the the interpreter during the execution of these commands may not be difficult.
But if it is impossible, then I suggest you withdraw Firefox until you have means to find the error. 

(In reply to comment #17)
M.S.C.A.M. de Rakovszky, thank you for your patience.  I realize that making Firefox stuff work is not your job, and I appreciate the time you've spent in helping figure this out.  That said, we are very short-staffed, so in general any help you can provide (such as simpler description of the problem, simpler page that shows the problem, etc) will significantly expedite problems being resolved.

If there are actually two bugs here, we should file two bug reports.  But I would suggest waiting until the event handler problem is fixed and seeing whether the other problem is still there, unless you have a clear testcase showing that the two are independent.  If so, please do file a second bug with that testcase and cc me, ok?

(In reply to comment #19)
Erik, if you're going to drive-by comment, please get your facts straight.  Bug 159849 is about _reading_ the on* properties.  This one is about _writing_ them inside a with statement.


bz: That bug was initially about setting on* props using |with|, but was resummarized later. I guess it's because it would make little sense if there was no such property on object, but setting it using |with| still worked. In normal JS if there isn't a property (or a setter), it is not added to the object:

js> with(o={}) x=1
1
js> o.x
js>
Blocks: 159849
#23:
It was not about properties, but about global variables being destroyed!!!!!!!!

Please do not change the summary to divert the spotlight from the main issue.

Any further csange of the summary will result in the publication of these proceedings, including attempts to side-track the problem.
You are free to generate new bug reports you find, putting me on the mailing list.
I want problems to be resolved according to their priority - as I see it.
This is but the first of a number of errors I am likely to report.
But anyone comparing the behaviour of the test-page when using FireFox and Maxthon/IE/Opera is bound to see the other errors as well.
But it could be, that these are causeb by the basic design-failure which causes the error I originally reported.
Summary: event handlers are not resolved when assigned to, unqualified (in with statements) → Variable suddenly becomes undefines, contents lost.
(In reply to comment #22)
> Erik, if you're going to drive-by comment, please get your facts straight.  Bug
> 159849 is about _reading_ the on* properties.  This one is about _writing_ them
> inside a with statement.

Then go on and reopen bug 275306 which _you_ marked as a duplicate of bug 159849.


Erik, my apologies.  I didn't read the other bug carefully enough, just the summary.

I agree that this is basically a duplicate; I'll fix that bug after which reporter of this one can see whether anything is still broken.
No longer blocks: 159849
Depends on: 159849
M.S.C.A.M. de Rakovszky - so you don't use firefox, and you aren't interested in helping narrow down the problem, that's fine, but that also means you relinquish any leg you might have had to stand on in making demands about how and when this issue is fixed. Besides we have managers and engineering teams for that.

If you wish, please feel free to drop by irc.mozilla.org to hash this out in person.  Find me in #firefox my username there is Lucy and I'll make sure you get some face time with the appropriate people.  Or if you prefer, email me at this address.

Now please leave this bug alone so that the *incredibly* competant people Mozilla has working on javascript (look up their credentials if you like) can deal with the issue that they see, unless you have more information to provide them.  Continued badgering usually results in bugzilla accounts being suspended, (although strange as it might seem to some, that also seems to result in bugs being fixed faster as the devs much prefer working on issues unharassed).

I'm reverting the summary to the one set by someone who provided a testcase.  We will be more than happy to set it to something else if we establish the other issue you're referring to.
Summary: Variable suddenly becomes undefines, contents lost. → event handlers are not resolved when assigned to, unqualified (in with statements)
re: #27
I do not use Firefox myself, but I want those who users of FireFox, who want to access my site (Which is going to contain a lot of historical research information) to ba able to do so. I do not want to keep the remark, that FireFox is useless for my site any minute longer than necessary.
Therefore I AM INTERESTED in resolving the problem.
I am VERY interested in getting the problem I reported, the one with I which started this bug-report.
If you read my report with open eyes, you will see, that I made it clear, that the loss of a variable is just the first of a number of errors that I was planing to report.
As it was hijacked by someone, and is continued to be so, I am forced to start  a new Bug-report with the original top-priority bug.
I hope it will not hijacked again.
I have provided all the necessary information for you to find the error.
You just have to monitor 3 (three) instructions in the function ArrowClick.
It looks all of you are afraid to tackle the real problem. As the actual line of code that is not executed correctly, causing the loss of the variable, may be at the end of a buffer, the problem might be some kind of buffer-overflow error. That the second Alert in ArrowClick is not executed, could mean, that it is beyond the end of a buffer and is lost together with the one preceeding it, which sets the value of the variable NextPict.
I know from experience, that to test this type of error is rather difficult. Any modification could mean that the corruption is transferred to another instruction. Than you have to hunt down that one.
I most strongly object to any accusation suggesting, that I am not trying to help.
For me, the simplest thing would be to declare on all forums and anywhere, where I show my URL, that "Firefox is unable to display it, please use Maxthon or InternetExplorer".
I could start to upload the information I am gathering, which is waiting for this bug to be corrected, and concentrate my attention to my research work. 
But you are right in one thing: as I do not use FireFox, I have no interest in its improvement, bug-fixes beyond those, that prevent my site being properly displayed. The event-handling problem is just a tolerable degradation, the loss of the variable is a disaster.
Please understand my point of view, and try to solve the main bug, instead of wasting my precious time in useless discussions, and the need to repeat the bug's description and how you can test it every time.



Sigh.

M.S.C.A.M. de Rakovszky, please feel free to resummarize the bug as you see fit -- you filed it, and unless and until you are satisfied that it is fixed by the patch for bug 159849, I see no reason to make it a duplicate of that bug.

People, let's try to use the bug system to find and fix problems in the code.  If someone's attitude or words bother you, take it up with them in email unless they are continuing in the face of past warnings to abuse their bugzilla privileges and abuse other people.

The reporter of this bug in my view is *not* abusing his privileges, and any impatience on his part, or even inflammatory rhetoric, is no excuse for responding in kind or "upping the ante".  Instead we should be glad the reporter brought to light an old bug that should have been fixed by now.

Almost all of us, certainly myself included, can stand to do better, both in hacking code and in the words that we write here.

/be
Thanks. For the record, the new one is bug 354383. I think it would be better not to dupe that one to this.
re #29;

Thanks for your words.
My irritation is caused by the fact, that when I first reported it as a possible Core-error, I did not even got an email acknowledging the report.
Then my originaly reported bug was replaced by another one (Which I was going to report after the top-priority one, losing data, was solved.
Some people gave me rather incompetent advices. 
Someone sidetracked the issue, bluntly speaking, hijacked my bug-report.
After that apparently noone war ready to read my description  of the error.
You cannot be supprised if I got irritated by misleading answers, etc.

I have taken the advice Alex Vincent gave me, and entered a new bug-report (354383) for the bug I reported here. I hope it won't be hijacked again.

Anyway the bug reported by me is not the one some people prefer to discus here, and is not a duplicate of 159849.
The problem of the event-handler, as far as my page is concerned, can only be investigated after the one reported by me. As in the top-priority case perfectly good code is not executed properly - and the place seems to be dependent on the size of the library, (buffer problem?) changing anything in any other part of the code may just transfer the corruption to some other function, preventing its quick and simple detection.
Blocks: 354383
Please read my comment #8 for bug 354383.

re #3:
Your comment drew my attention to the keyboard, and the advisability to allow the navigation between the pictures through the keyboard.

After implementing that, I will be able to check the other discrepancies withou the mouse, that is bypassing the bugs causing the critical errors on my page.
re #3:
Your comment drew my attention to the keyboard, and the advisability to allow the navigation between the pictures through the keyboard.

After implementing that, I will be able to check the other discrepancies withou the mouse, that is bypassing the bugs causing the critical errors on my page.
Sorry for #33 and #34. It was intended for 354383. (#3 refers to the comment there, that if instead of mouse, the space-bar is used, the "missing" alerts are displayed as they should be.
Whiteboard: [should be fixed in 159849]
Bug 159849 fixed on trunk.  Reporter, could you possibly try tomorrow's trunk build and see how things look?  It should be in http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ (and you'll  want to make sure it's dated Oct 7).  Be careful to run it with a brand-new profile (using "Firefox -ProfileManager" and creating a new profile for that run, then running your existing 1.5.0.x build with -ProfileManager and switching back to your old profile) so that it won't mess up your existing profile.
My aim is to test that my code works with FireFox too, and not to test firefox. I just do not have the time for it. Anyway currently I am suffering from an attack of the flu, so ...
1.)I have deinstalled firefox on the win-2k pc, so I cannot go back to older versions/profiles.
2.) I have implemented the suggested workabout for the with.
3.) I am willing to  install a version of FireFox, but only such a version that has a future. If 1.5 is buggy, but 2 is OK, I can alway advise the would-be readers to use FF-2. 
Please advise me, if the latest version of FF-2 is suitable for testing on Win-2k, especially, that some errors that occur on my PC do not occur on the Win XP machine.

The fix for bug 159849 will be in Firefox 3, not Firefox 2.  Firefox 2 has been in code freeze for several weeks at this point.
Not a blocker bug. Anyone know if bug 159849 fixed this or not?
Flags: blocking1.9? → blocking1.9-
I'm going to mark this invalid, actually -- no testcase anymore, no response from reporter, problem doesn't exist in my testing.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.