Closed Bug 354383 Opened 18 years ago Closed 18 years ago

Exception thrown from onmouseover, while an alert dialog is visible, makes statements after the alert not execute

Categories

(Firefox :: General, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: mscam_de, Unassigned)

References

()

Details

Attachments

(1 file)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Maxthon; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: 

in the following javascript code:
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

if (MonitorMe)
   alert (WhoAmIText+"  ArrowClick-0  TrNr="+TrNr+"  CurrPosit="+CurrPosit);
gets executed, the following on not.

The next message is the the alert in the function ThumbClick.
This function follows immediatelly after the ArrowClick, and is called by ArrowClick as its last step.



Reproducible: Always

Steps to Reproduce:
1.load the start-page of
www.rakovszky.info
2.click on the link "FireFox-Test" on the left side.

3.click in the downward arrow immediatelly under the happy-icon next to the thumbs.

4. Observe the Alert messages displaying the value of the variables.


Actual Results:  
The function is not executed properly.
Either part of it is not loaded into the memory, (Buffer overflow?)
or the simple instruction
  	var NextPict = CurrPosit + TrNr;
causes such an error, that the rest of the function is not executed.
(but then why is the function ThumbClick entered.

Expected Results:  
Run the same using Internet Explorer, Maxthon or Opera to see, what should happen.

This error was already reported twice. Once as an error in the core. Nothing has happened, not even an acknowledgement has been received.
Then on the 24th (MEST), 25th (PDT).

quote from there:
...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"

Instead of investigating the bug I reported, some other further down my priority list were observed and the original bug-report was hijacked for that error.
In wain have I pleaded for the investigation of the bug I reported, I only found stone-walling and a lack of understanding for the real problem.
(by the way, some of those helping to investigate the bug, displayed a certain lack of competence, for example, declaring the "onMouseOut" to be an undeclared variable, to mention just one.

Please do not try to click on any other button, arrow, picture, just on the one I specified.
When this problem is solved, or at least the cause discovered and described, there is time for the other bugs I found. It could be, that they cannot be tested properly until this bug is solved.

As my page works properly using other browsers, I am not dependent on FireFox, but I want those who swear by it, to be able to access the information on my pages.
If this bug-report is hijacked again, I will abandon any further cooperation and report it to organisations specialising in investigating possible security risks.
If you come to the conclusion, that you see some other error, write your own bug-report about it, and I will help to pinpoint it. 

Please do not change the summary without first discussing the change with me.
Any onesided chage will be regarded as sabotaging the investigation of this error, and interpreted as an attempt to hide some backdoor built into Firefox by one of the many authors.
For the record, this started in bug 354119.
Yes it was started in bug 354119.
Unluckily that was sidetracked/hijacked for the error which I was going to report after this problem is resolved. (If it still exists then).
I hope we can work constructively on this, without adding confusing side-issues to it.
I want to get on with my work, which is delayed by these bugs. (I want my site to be displayable bothe by IE (and its derivatives like Maxthon) AND FireFox, especially that many Linux users prefer FireFox to other browsers.
The alert is not being called because of the exception thrown from the mousemove handler. ThumbClick gets called because you set a global click handler on window on line 69: onclick = function() {ThumbClick(this.rowIndex );}; (because of the other bug you claimed was irrelevant)

Note that if you dismiss the alert with spacebar, the second alert *is* shown.
(Click on the page, then click on the ok button to reproduce.)

> I expect a reply within 24 hours.
It's unreasonable expectation generally, since there's huge number of bugs being filed every day, many of which are poor quality, and there are few people doing triaging.
Severity: critical → normal
Bug 337227 sounds related, but involves timers rather than mousemove events happening at odd times.
See also bug 324149, "Moving into an alert window sends a mousemove event".
Depends on: 354119
Reporter, does the testcase in comment 3 correctly reflect the issue this bug is about?
Depends on: 324149
First of all, I want to thank you all for the work you have done in finding the cause of the unexpected behaviour.
 re #3:
Thanks for pointing out, that if I use the space-bar to dismiss the alert window, the next step is executed properly.
As the page is designed for mouse actions, it has never occured me to use the space-bar. Thus I have made som false assumptions. (I am sorry for the confusion caused by my one-track(ball) mind. - I use a Trackball, and have my hand on it all the time, when I do not actually type something.)
Pity that this suggestion did not come up in the original bug-report. It would have saved lot of arguments and irritation on all sides.

re #4: I have reported this bug some time ago by the core-bugs, because it happens in Netscape. I am still waiting for a reply.
For me, a simple confirmation of having received the bug-report is a sufficient reply. You people have done much better. Thank you.


re #7: Yes, at this moment it look like that. But I will have to do some more tests to analyse the problem. 
I have deleted the original summary, and would like to ask someone well versed in your bug-description, to write one, which truely reflects the causes and effects.

What do you think, how long will it take to remove the error? Days? Weeks? Months?

I have to know how to proceed with
1.) my site
2.) reporting further errors (they all may do away if this bug is removed.)
I just do not want to waste your or my time.

I agree, does it is no longer critical as far as FireFox is concerned(for me it remains critical), but whether it is to be classified as normal or serious depends on the classification of the other bugs.

Anyway, a bug that creates effects, that cause such errors that the user thinks, there is another, quite different one could still be classified as critical, because after correcting it, you would receive less (misleading/unnecessary) bug-reports. Saving your time is enough to justify the declaration of a bug to be critical.
Perhaps all bugs concerning mouse actions should be automatically classified as critical. The user, web-designer is mostly not in the position to connect a mouse-movement over some "field" with the unexpected reaction somewhere else.
Especially when he uses a pen-and-tablet. (On pages where I have to spring from one point to another farther away, I prefer the tablet.) He may not even noticed, that he moved the mouse over the field.



Summary: Firefox loses variables, could be a buffer-overflow problem. - In a javascript function consisting if 6 instructions (3 of them for debugging) the code after the first one is not executed, and it falls through to the next function → Please change according to your best judgement
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.
> Pity that this suggestion did not come up in the original bug-report. It would
> have saved lot of arguments and irritation on all sides.
> 
True, but only in the comment 0 here I saw the clear steps to reproduce and the snippet of code (ArrowClick) that indicated there was a problem in Firefox rather than in your code. Thanks for your patience and the detailed report you wrote here.

> re #4: I have reported this bug some time ago by the core-bugs, because it
> happens in Netscape. I am still waiting for a reply.
Are you talking about a bug reported in this bugzilla? If so, what's the bug ID? I see only two non-security bugs reported using your current account. 

> What do you think, how long will it take to remove the error? Days? Weeks?
> Months?
> 
Depends on whether someone will work on it for Fx3. In any case, likely not earlier than Fx3 release (somewhere in 2007). Same for bug 354119, which exposes this problem.

> I have to know how to proceed with
> 1.) my site
I suggest fixing the exception that gets thrown from the mousemove handler. You probably don't want your users to wait until the next major release of Fx to use your site.

> 2.) reporting further errors (they all may do away if this bug is removed.)
> I just do not want to waste your or my time.
> 
Reports with minimized testcases are very welcome. If you don't have time to create such a testcase, you can still log the bug as long as you provide clear steps to reproduce and make it obvious the bug is not in your code, like you did in this report. Naturally, investigating bugs without testcases takes longer and they are likely to turn out to be duplicates of other known bugs.

> Perhaps all bugs concerning mouse actions should be automatically classified as
> critical.
While compatibility with web pages is important for us, 'critical' is used for other kinds of bugs: crashes, dataloss, security holes. Also, you should agree this is an edge case, normally pages don't throw exceptions from the mouseout handler.
Version: unspecified → Trunk
re #10:
"re #4": No, it was some Hendrix report-system or whatever it is called. (Probably you know much better than I what it could be. But it is an old hat now.)

I will have to read all the comments in 354119 to see how I can fix it in my code.
Through some incompetent comments, and through those which are meant for insiders, I am confused a bit at the present.
If you can suggest in one or two sentences the best work-aroung, I would be grateful.

I must confess, I have a lot of problems with FireFox itself, but I do not regard them as bugs, they are due rather to my little experience with this browser, and the lack of time to pay attention to its use. (for example, I still did not manage to activate its tabbed function. But for testing my site, I do not need it.) My standard browser is Maxthon, and some time ago - before starting my research-project and creating my web-site - I was very active on the Maxthon forum, helping users with their problems. 

Some time ago I downloaded a syntax-checking program/function for FireFox, but did not manage to get it working. Perhaps you know of one, which I could download and use, before complaining.
At the present, my possibilities consist of the syntax-checker in Adobe's GoLive and that available in Internet Explorer.
Of course, they only show cases (if at all), where Internet Explorer objects to something. Even then it may be difficult to pinpoint the exact instruction.

There is one very important difference between Maxthon and Firefox:
Maxthon is not so sensitive to the punctuation. Often it recognises the end of a statement, even if the closing semicolon is missing.
So if I find that something does not work in Firefox, that is OK in Maxthon, I must go through all the code, checking each statement for the closing semicolon.
This can be very tiring.

What I would expecct from such a syntax-checker, is that it would flag   statements where:
1.) the semicolon may be missing, rather ten too many as one too few reports.
2.) those lines, which use features that are implemented in IE, but not in FireFox,
3.) those lines, which include features whose implementation in FireFox differs from that in IE.
4.) those lines that use a feature, which may not work due to a known bug in FireFox.
(This would possibly reduce the number of duplicate bug-reports.)
There could be a kind of Knowledge-base, giving possible workabouts for the known bugs, identified by a suitable bug-report number.)
5.) possibly: marking cumbersomely coded instructions, which could be simplyfied.
(it would reduce download and interpretation time.)

In my experience (here too), minimalised test-cases can back-fire, if the cause is the interplay of a number of different factors.
I prefer to modify the full code to selectively monitor the error. (This feature is already built in for my code.)

I think that a bug, that causes the user/web-developer to bark up the wrong tree, reporting the false things (like in my case) thus making the detection of the actual bug more time-consuming, should be classified as critical.
As one of you stated, most of you are unpaid volunteers (which I appreciate), any error that causes further (apparent) errors, should be repaired at once, so that you do not waste your time.

If you find differences in JavaScript semicolon insertion between IE/Maxthon and Firefox, it's a bug in or the other, because the ECMAScript spec says exactly when semicolons should be inserted.  If you find differences that you think are due to bugs in Firefox, please file bug reports.
Summary: Please change according to your best judgement → Exception thrown from onmouseover, while an alert dialog is visible, makes statements after the alert not execute
> "re #4": No, it was some Hendrix report-system or whatever it is called.
Oh, you don't get replies to that feedback, and you're warned about it on the submission page.

> If you can suggest in one or two sentences the best work-aroung, I would be
> grateful.

The workaround is to not use |with| to set the on* handlers. Other errors may show up in JS Console, which you'll need to fix as appropriate.
E.g.:
with(TR) { onclick = function(e) {...} }
becomes
TR.onclick = function(e) {...}

> Some time ago I downloaded a syntax-checking program/function for FireFox, but
> did not manage to get it working. Perhaps you know of one, which I could
> download and use, before complaining.
Just use the built in JavaScript Console (Tools menu). When an error occurs, it is displayed there along with the line of the source code it occurred on.
re #12:
I would not call it a bug in the other browser. "Feature" would be a better description. In many cases, it is possible the recognise from the context, where a certain instruction ends.

I described the problem, because if something does not work in FireFOx, I have to check for missing semicolons. That is the most frequent error in my code that I encountered.

re #13:
1.) I did not see, that Hendrix does not respond.

2.) thanks for the suggestion. I assume that it is necessary only for those parts of the code, where the code in the With-structure refers to onMouse functions.

3.) Thank you for the tip about the Javascript console.
I have tried it, but have some problems with it:
First the good news, it pointed ot some errors that I could resolve, e.g cursor=hand is not OK in FireFox, only Cursor=pointer. IE/Maxthonaccepts both.
(I have to mention Maxthon, because on my PC for some reason IE works only for local files, while with Maxthon I have no problem accessing the net.)
The console also throws out features which are IE specific, like the scrollbar-xxx-color definitions.

But now comes the bad news: the line-numbers of many errors do not point to any instruction with a possible error.
This could be due in some cases to empty lines used to improve legibility, but others cannot be explained by this:

Error: Error in parsing value for property 'width'.  Declaration dropped.
Source File: http://www.rakovszky.info/
Line: 0
Error: Error in parsing value for property 'height'.  Declaration dropped.
Source File: http://www.rakovszky.info/
Line: 0
Could this refer to some code in the javascript library?
I am setting special attributes of width and height for various areas, to compare the is and should values.


Some of the errors shown seem to be caused by the media= parameter in
<style type="text/css" media="all"> 
as far as I am aware, it is a perfectly legitimate statement.
Error: Selector expected.  Ruleset ignored due to bad selector.
Source File: http://www.rakovszky.info/Greetings_Info.html
Line: 12
If I am correct and it is just ignored, little harm is done untill someone tries to print the page. (I did not test this as yet, but someone did print out a page of my website, because he found a number of errors in the German text. It was printed in small-caps - I forgot to set the media to all.)
This discussion is not really appropriate for bugzilla, you can continue in a relevant mailing list or on IRC. Feel free to CC me, if you wish.

> 2.) thanks for the suggestion. I assume that it is necessary only for those
> parts of the code, where the code in the With-structure refers to onMouse
> functions.
> 
No, this change must be made for all the on* handlers.

> Line: 0
This means that the line number couldn't be identified. In case of JS errors, this is most likely some code in an on* *attribute* (i.e. <button onclick="..">). Not sure if CSS has a similar problem.

Since this bug is basically a dupe of the two bugs Jesse found and has a lot of irrelevant to the bug discussion in it, I'll close it. Feel free to CC yourself on the mentioned bugs if you wish to track their status.

Have a nice day.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: