On Fri, Mar 23, 2012 at 11:12 AM, Silenio Quarti
<Silenio_Quarti@xxxxxxxxxx> wrote:
There are situations where the metrics
cannot be calculated or need to be updated after the creation of the editor.
the height is zero as well, if the editor is connected to the DOM
but one of its parent has display: none. If CSS changes dynamically
after the editor is created, the metrics/lineHeight could be out
of date. The editor could detect the first two cases during creation,
but not the last one. I do not think that giving up and throwing
an exception in the creation of the editor will help a user/app that knows
about these issues and is prepared to call update(true) when necessary.
Ideally, the editor should detect that the metrics is out
of date and recalculate it, but I do not know how this can be done.
I have seen cases (in Firefox/IE) where
the editor would lose the caret and the ability to edit. Sometimes, switching
focus to another app and clicking back in the editor would bring the focus/caret
back.
When you click on the editor, focus() should be called from handleMouseDown().
In my case focus() is not called from handleMouseDown() because this._hasFocus is true. That property is set true by _handleFocus().
Any other ideas?
jjb
I have not seen this with chrome, so you are probably hitting a different
problem.
Silenio
On Fri, Mar 23, 2012 at 8:36 AM, Silenio Quarti <Silenio_Quarti@xxxxxxxxxx>
wrote:
Another way to get the editor to recalculate the metrics is by calling
textView.update(true) after it has been connected to the DOM. I
think the editor should be able to do this for free somehow. I cannot
detect when the editor gets connected, but I could update the metrics when
resize() is called and the previous height calculation was zero.
I am not sure this would help much, since resize() still has to
be called.
The metrics need to be correct, so I think simply throwing
an error if the height is zero would help. Or better, throw if calculateMetrics()
is called when the editor is not connected to the DOM. That points
directly at the issue.
For editing, does it help to switch focus away from the editor and back
by clicking in another application?
No. I see that
this._editor.getTextView().focus();
is called when the file selection operates. Switching
focus out of the app and back does not do anything I can see and it does
not cause the above call.
Does this indicate something?
jjb
Silenio
I made a bit of progress in understanding this problem.
The ruler elements have height 1px because that default set instead of
zero. The _calculateMetrics() function measures a blank character, discovers
the character has no height and falls back 1px.
This measurement fails because the _clientDiv is not in the document during
the calculation.
By calling the resize() operation in WebInspector's wasShown(), I get a
partial recalculation, but not for the ruler, that seems to be a one time
deal.
The WebInspector rendering sequence seems to construct the object, issue
willShow event to the object's children, add the object to the document,
then issue wasShown().
I am creating the editor at the object construction time, but somehow I
need to delay the calculateMetrics( ) until wasShown().
I moved my call to editor.installTextView() from construction to wasShown().
Now the rulers are correct!
Still can't edit however.
jjb
On Thu, Mar 22, 2012 at 7:46 AM, Silenio Quarti <Silenio_Quarti@xxxxxxxxxx>
wrote:
Are you calling textView.resize() anywhere?
embeddededitor.html does not have to call resize() because the div that
hosts the editor is filling the page. Anytime the window resizes, the editor
resizes itself.
If the editor does not fill the page in WebInspector, you need to call
resize() anytime the page is layed out.
Where is the editor used in WebInspector?
Silenio
On Wed, Mar 21, 2012 at 11:39 AM, John J Barton <johnjbarton@xxxxxxxxxxxxxxx>
wrote:
On Wed, Mar 21, 2012 at 11:16 AM, Silenio Quarti <Silenio_Quarti@xxxxxxxxxx>
wrote:
You might have problems with drag selection on Chrome. If the editor is
inside of an IFRAME, it will not receive mouse move events (while dragging)
when the mouse is outside of the editor (IFRAME). The editor had a work
around that would hook mouse move listeners in the outer document. This
work around was removed.
You may also have to convert coordinates returned by the editor since these
coordinates will be relative to the IFRAME. This might not be an issue
if you do not talk to the editor from the outer document.
What kind of styles are affecting the editor? I am curious to see if it
is something the editor should try to fix. For example, I know that setting
lineHeight on a parent of the editor affected it badly, so I had to overwrite
it.
I don't know. Instead of line numbers I have two black streaks; The
.rulerLines have height 1px. WebInspector has
* {
-webkit-box-sizing: border-box;
}
I don't have a cursor but maybe I am not dealing with focus.
In WebInspector, the editor seems to render all of the source lines (148). When
I click on the textView, the Selection is set to the end of the buffer
(both start and end). That line is not visible.
There is no scroll bar on the left.
In the reference page only the viewport lines are rendered and there is
a scrollbar.
jjb
jjb
Silenio
I have been able to get the new embeddeditor to 'work', that is to show
some text. But I think my next step is to put it back in an iframe. The
problem I have is that the styles from the containing page (Web Inspector)
prevent the editor from working. I could try to find all of the style problems
and fix them by rules that work on .orion-editor, a div I put around the
editor. But to me the iframe path seems attractive. The issue about the
bug on mobile safari does not concern me. Any other issue I should
know about?
thanks,
jjb
On Fri, Mar 9, 2012 at 10:02 AM, Silenio Quarti <Silenio_Quarti@xxxxxxxxxx>
wrote:
None that I can foresee. There was a change in the in embeddededitor.css/embeddededitor.js
to move the stylesheet that used to be passed in the TextView creation
into the page HTML, but I believe that does not affect you.
Silenio
On Thu, Mar 8, 2012 at 1:17 PM, Silenio Quarti <Silenio_Quarti@xxxxxxxxxx>
wrote:
I have merged the changes to remove the IFRAME that hosts the editor into
master.
Unfortunately, some APIs in TextView had to be removed since they only
made sense because of the IFRAME. Hopefully I have updated all the
places that made use of them in Orion. Please let me know if I missed any.
Sorry about other users of the editor. Let me know if you need help
updating.
Any special issue for use of the embedded editor example?
jjb _______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev