Opera: Panels are displayed in the wrong position

[Frederico Caldeira Knabben]

All floating panels in the toolbar are being placed in the wrong position, aligned to the very top boundary of the editor space.

[Frederico Caldeira Knabben]

Actually the panel test page (_test/manual/fckpanel/test1.html) is not working at all with Opera.

[Alfonso]

I've tried to debug it and have found that the problem is in FCKTools.GetElementPosition Opera is returning the same values for both el.offset* and el.scroll* properties so it always says that it's at (0,0)

[Frederico Caldeira Knabben]

If you believe it is a bug on Opera, we can report it to them. Can you provide a reduced test case for it?

I've just created the "Compatibility" page with useful information you still don't know. Please take a look there.

Also, just a tip... if you start working in a bug, please accept it here (the "Action" block at the end of the ticket) as your first action. In this way you avoid others to start working at the same issue. Then, if you can't or don't want to work in this issue anymore, you can reassign it.

[Alfonso]

I've moved the code to just two files. The problem only happens trying to read the properties in an iframe, but not all the elements in an iframe fails (the iframe itself does fail)

I'm attaching the two files so it can be reported to Opera, maybe we could workaround it, but I think that it's much better if they can fix it instead of creating complex code.

I should have marked that I was looking it, but it was more a check of my SVN problems, first real look at the problems Opera and the testcases available. I knew that I could fix it today so I can't accept it.

[Alfonso]

inner frame

[Alfonso]

test file to get any element position

[Frederico Caldeira Knabben]

Great job again Alfonso.

As you have noted, the bug in Opera is that scrollTop and scrollLeft return the offsetTop and offsetLeft values, which is wrong.

The Test Case you have provided is ok for a initial investigation, but it too complex for a bug report at Opera. They expect to have a "reduced test case" or "mininum test case" that goes straight to the bug in a page as simple as possible. In this way we have more probabilities of having the bug fixed soon.

I was about to create a test case for it, but I've found the following bug report at Opera: ​https://bugs.opera.com/show_bug.cgi?id=165620

I know you are not able to see it. The link is here just for documentation.

I'm attaching the test case they have proposed there, so you can understand what I'm talking about.

It seams the bug has been fixed a few days ago (05/12) and so we can expect to have it fixed soon in some build. I'll close it as soon as it is published.

I'm explaining you all those things to introduce you some ideas and to define with you our development model. Please don't take my comments as criticism, because you are really doing a great job.

Thanks again.

[Frederico Caldeira Knabben]

Opera's scrollTop TC

[Frederico Caldeira Knabben]

I've just added the directory _dev/browserbugs to the SVN with all TCs I have for known bugs (some already fixed maybe).

[Hallvord R. M. Steen (Opera Software)]

Fix should go public in Opera 9.5.

[Hallvord R. M. Steen (Opera Software)]

assigning to self since it needs Opera fix

[Frederico Caldeira Knabben]

My last tests with Opera build 9418 show that this one has been fixed. There is a different problem now (see #570).

So, feel free to close this one if you feel ok with it Hallvord.

[Hallvord R. M. Steen (Opera Software)]

It is fixed (actually this is one of the most important DOM fixes, lots of complex JS apps have run into it. We should really celebrate the death of this bug :-D )

[Frederico Caldeira Knabben]

Replying to hallvord@opera.com:

It is fixed (actually this is one of the most important DOM fixes, lots of complex JS apps have run into it. We should really celebrate the death of this bug :-D )

Cool! Cheers!