Caret fails to show on FF4.0 with Orion Editor

RESOLVED FIXED in mozilla5

Status

()

defect
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: johnjbarton, Assigned: Ehsan)

Tracking

Trunk
mozilla5
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

8 years ago
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.
Assignee

Comment 1

8 years ago
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?
Reporter

Comment 2

8 years ago
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
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?
Summary: Cursor fails to show on FF4.0 with Orion Editor → Caret fails to show on FF4.0 with Orion Editor

Comment 4

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

Comment 5

8 years ago
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

8 years ago
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

8 years ago
Forgot to mentioned I am running

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

Comment 8

8 years ago
My patches in bug 407127 help here to some extent, but there is more work to be done here.
Assignee: nobody → ehsan
Depends on: 407127
Whiteboard: [post-2.0]

Comment 9

8 years ago
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).
Assignee

Comment 10

8 years ago
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.
Assignee

Comment 11

8 years ago
Posted patch Patch (v1)Splinter Review
Attachment #518858 - Flags: review?(roc)
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?
Assignee

Comment 13

8 years ago
(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.
Assignee

Updated

8 years ago
Depends on: post2.0
Assignee

Comment 14

8 years ago
http://hg.mozilla.org/mozilla-central/rev/abca61b0be19
Status: NEW → RESOLVED
Last Resolved: 8 years ago
No longer depends on: post2.0
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [post-2.0]
Target Milestone: --- → mozilla2.2
You need to log in before you can comment on or make changes to this bug.