639695 - Caret fails to show on FF4.0 with Orion Editor

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect)

Description

[John J. Barton]

1. Install orion http://wiki.eclipse.org/Orion/How_Tos/Install_Orion_on_Localhost

use the Lastest releease
0.2 Stream Stable Build	0.2M5

after step 7 of the instructions (you login) you should see a couple of folders. Pick any file in there to bring up the editor. 

But the editor has no cursor. Works on FF3.6.

Comment 1

[(no longer active)]

Hmm, I gave this a quick try on Mac and couldn't reproduce.  I opened a bunch of files in the test server you sent to me by email, and the cursor showed up at the beginning of all of the files that I tried.

Does this happen to you on a clean profile, every time?  What platform have you tried it under?  Which nightly did you test this on?

Comment 2

[John J. Barton]

I just repeated my test using 
http://localhost:8080/coding.html#http://localhost:8080/file/org.eclipse.orion.client.editor/web/index.html

Here is about:support:

  Application Basics

        Name
        Firefox

        Version
        4.0b13pre

        User Agent
        Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre

        Profile Directory

          Open Containing Folder

        Enabled Plugins

          about:plugins

        Build Configuration

          about:buildconfig

  Extensions

        Name

        Version

        Enabled

        ID

  Modified Preferences

      Name

      Value

        accessibility.typeaheadfind.flashBar
        0

        browser.places.importBookmarksHTML
        false

        browser.places.smartBookmarksVersion
        2

        browser.startup.homepage_override.buildID
        20110303122446

        browser.startup.homepage_override.mstone
        rv:2.0b13pre

        browser.tabs.warnOnClose
        false

        extensions.lastAppVersion
        4.0b13pre

        network.cookie.prefsMigrated
        true

        places.history.expiration.transient_current_max_pages
        104660

        privacy.sanitize.migrateFx3Prefs
        true

  Graphics

        Adapter Description
        ATI Radeon HD 4300 Series

        Vendor ID
        1002

        Device ID
        954f

        Adapter RAM
        512

        Adapter Drivers
        atiumdag atidxx32 atidxx64 atiumdva atiumd64 atiumd6a atitmm64

        Driver Version
        8.632.1.2000

        Driver Date
        8-17-2009

        Direct2D Enabled
        Blocked on your graphics driver. Try updating your graphics driver to version 10.6 or newer.

        DirectWrite Enabled
        false (6.1.7600.16385, font cache n/a)

        WebGL Renderer
        (WebGL unavailable)

        GPU Accelerated Windows
        0/2

Comment 3

[Mats Palmgren (inactive)]

I can reproduce it on Linux.
I see the caret when a file is opened for the first time, but a Reload
makes the bug occur - no caret even though the document is still editable.
Maybe the same underlying issue as in bug 467333 / bug 407127?

Comment 4

[Boris Bokowski]

The corresponding bug on the Eclipse side is here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=335505

Comment 5

[Silenio Quarti]

This problem can be reproduced by hidden and showing a DIV that has contentEditable set (style.display="none"). See 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=334587

Comment 6

[Silenio Quarti]

Here is a sample that can reproduce the problem without the orion editor.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=334587#c3

Comment 7

[Silenio Quarti]

Forgot to mentioned I am running

Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12

Comment 8

[(no longer active)]

My patches in bug 407127 help here to some extent, but there is more work to be done here.

Comment 9

[Boris Bokowski]

Just to let you know, we have a workaround on our side now (that we're not happy with but it does make the Orion editor not lose the caret on Firefox 4).

Comment 10

[(no longer active)]

This is the reincarnation of bug 284245 for contenteditable documents.  What happens is that when the presshell changes for an iframe containing a contenteditable document, the editor loses its connection to the selection objects, and won't gain it back until nsEditor::InitializeSelection is called for some reason (most common: the editable area losing and regaining focus).

I have a patch to be applied on top of the patches in bug 407127 which fixes this bug.

Comment 11

[(no longer active)]

Attachment: Patch (v1)

Comment 12

[Timothy Nikkel (:tnikkel)]

The testcase from comment 6 fails in Firefox 3.6 for me, but comment 0 says that the problem does not occur in Firefox 3.6. Are we looking at two different bugs here?

Comment 13

[(no longer active)]

(In reply to comment #12)
> The testcase from comment 6 fails in Firefox 3.6 for me, but comment 0 says
> that the problem does not occur in Firefox 3.6. Are we looking at two different
> bugs here?

No.  The Orion editor is really complex, so whether or not that would fail depends on a lot of factors, but the bug has been there since forever, and it's been something that I wanted to fix for a long time.

Note that anything which can trigger an InitializeSelection call would "work around" this issue, but that doesn't mean that the bug doesn't exist.

Comment 14

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/abca61b0be19