Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 363508 - Selection is broken after TextView hide/unhide
Summary: Selection is broken after TextView hide/unhide
Status: RESOLVED FIXED
Alias: None
Product: Orion
Classification: ECD
Component: Editor (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 0.4 M1   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-10 12:17 EST by Mihai Sucan CLA
Modified: 2011-12-01 17:00 EST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mihai Sucan CLA 2011-11-10 12:17:02 EST
STR:

1. Initialize the Orion editor.
2. Toggle any of the Orion parent element.style.display to 'none' then back to 'block'.
3. Start a selection with the mouse.

Expected result: selection should follow the mouse.

Actual result: selection starts from the bottom of the view and ends at the mouse location, and you have flickers during mouse moves.

One artificial condition that needs to be met: disable the DOMAttrModified event handler which destroys/creates the view when the editor visibility changes.

Why: in Firefox the entire Orion editor is inside an iframe. When we hide the parent iframe using display:none, the DOMAttrModified event handler is not invoked. When we show Orion back ... selection is broken.

This is needed for our Style Editor developer tool which maintains multiple editors per CSS file, inside the same window. Functionality relies on the ability to hide/show each editor as needed.

Things to take into consideration:

- for our integration purposes the DOMAttrModified event listener is inoffensive - causes no performance degradation for the devtools that contain the SourceEditor component that uses Orion (luckily), and we would not want the event listener to be able to transcend nested levels of iframes.

- for performance concerns we would also want to avoid the view destroy and creation processes. We can ensure that none of the Orion editor APIs are called when the editor is not visible. We just want a quick hide/show approach.

Thank you!
Comment 1 Mihai Sucan CLA 2011-11-10 12:38:24 EST
Awesome! This is now fixed in Orion.

The fix I had prepared for our Orion version was to call e.preventDefault() in Firefox from _handleMouseDown() (it was only for Opera and Chrome). It looks like the latest Orion changes include this as well.

Changing the parent element.style.display to none then back to block no longer causes the selection breakage.

I am not closing this bug for the moment, because I need to integrate the latest Orion into Firefox. Will see how that goes and I'll close the bug when I can confirm the latest Orion works in our Style Editor.

Thanks for your work!
Comment 2 Felipe Heidrich CLA 2011-11-10 15:22:26 EST
The e.preventDefault() in mouse down was added because we removed the overlayDiv.

We also changed the way we handle non-requirejs setups, if you don't have requirejs you should include:
<script src="../../orion/textview/global.js"></script>

Finally, we changed the signature of addEventListener() to match that of W3C (see Bug 349957). All our types are using that now (view/editor/model/annotation model/etc).

If you have any problems with the integration please let me know.
Comment 3 Mihai Sucan CLA 2011-11-10 16:19:07 EST
(In reply to comment #2)
> The e.preventDefault() in mouse down was added because we removed the
> overlayDiv.
> 
> We also changed the way we handle non-requirejs setups, if you don't have
> requirejs you should include:
> <script src="../../orion/textview/global.js"></script>
> 
> Finally, we changed the signature of addEventListener() to match that of W3C
> (see Bug 349957). All our types are using that now
> (view/editor/model/annotation model/etc).
> 
> If you have any problems with the integration please let me know.

Thank you very much!

Yep, I've seen there have been some important changes. Thanks a lot for your explanation.

I am mostly worried by the DnD landing, but more details on that once I test it.
Comment 4 Mihai Sucan CLA 2011-11-14 16:53:27 EST
(In reply to comment #2)
> The e.preventDefault() in mouse down was added because we removed the
> overlayDiv.
> 
> We also changed the way we handle non-requirejs setups, if you don't have
> requirejs you should include:
> <script src="../../orion/textview/global.js"></script>

We don't use requirejs, we just include Orion. global.js looks like what I need, but it seems to be missing a minimal require() implementation. Currently it has only a minimal define().
Comment 5 Felipe Heidrich CLA 2011-11-18 15:22:52 EST
Hi Mihai, do you still need this bug ?
Comment 6 Mihai Sucan CLA 2011-11-18 15:27:07 EST
(In reply to comment #5)
> Hi Mihai, do you still need this bug ?

No. Thank you!

I was going to triage the open bugs when I complete the next Orion update, but I can confirm that this bug is indeed fixed with the latest Orion inside our devtools.

(btw, the Style Editor is ready - you can test it in the latest Firefox nightlies!)