457600 - <panel> moveTo function moves the panel but the panel returns to it's orginial position.

Status: UNCONFIRMED

(Toolkit :: UI Widgets, defect)

Description

[gilad.kutiel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.30 Safari/525.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

I move a <panel> element, using the moveTo function.
The panel moves fine.
The panel doesn't receive mouse/keyboards events in its new position.
After a while the panel moves back to its original position. 
(this bug appears whether the panel has a child iframe element or not) 

Reproducible: Always

Steps to Reproduce:
1. install the extension in the supplied url.
2. open Firefox, you should see a fisheye menu at the bottom of the browser.
3. click on one of the links, a panel should be opend.
4. drag the panel around.
5. move your mouse over the fisheye menu, the panel should jump back to its original position.
Actual Results:  
the panel jump back to its original position.

Expected Results:  
the panel should not jump back to its original position.

Comment 1

[Pavlos Touboulidis]

I get the same results here. I worked around it by setting panel.left and panel.top (to integer values) instead of calling moveTo but my panels flicker a lot when moving (not sure if it's the bug or something I do wrong).

Comment 2

[Neil Deakin]

The testcase url is no longer valid. Please attach a simple testcase (just a single xul file is preferred) as an attachment.

Comment 3

[Matthew Tuck [:CodeMachine]]

I've had the same problem with an extension I'm trying to upgrade to the V3 line, that I've had to port to popups instead of fixed positioning over the browser.

My extension allows the user to drag the popups so the coordinates can't be supplied to openPopup ... like I've seen mentioned on other bugs.

I have tried hide followed by open as a workaround but it looks like there's bugs in open too, and setting left/top doesn't seem much better.

Anyway, I will attach an overlay as a simple test case.  It will add a button to the status bar.

Comment 4

[Matthew Tuck [:CodeMachine]]

Attachment: Popup Drag Test Case

Comment 5

[Matthew Tuck [:CodeMachine]]

Attachment: Popup Drag Test Case (Fixed)

Oops, fixed the bug in the last test case.

Comment 6

[Matthew Tuck [:CodeMachine]]

Note that the position reset doesn't happen immediately, it seems to be reset by a window move or a hover effect in the browser.

Also it looks like the popup is incorrectly offset too, the panel top-left should be equal to the pointer, it isn't for moveTo but does for the workarounds.  It seems this offset this is dependent on the browser window's position, and a non-maximised window in the centre of the screen provides a bigger offset than a maximised one - indeed often when you click the popup it disappears offscreen to the left.

Ignore my comment about hide/open not working, I was using the wrong coordinate system in my first patch, it does seem to work, albeit uglily, as you can see from an uncomment on the test case.