In nsEditor::InsertTextImpl we find this code:
if (mComposition) {
...
} else {
if (node->IsNodeOfType(nsINode::eTEXT)) {
...
} else {
// we are inserting text into a non-text node. first we have to create a
// textnode (this also populates it with the text)
node->AsElement()->List(stdo
I am having second thoughts. If I understood correctly, the idea is to
continue adding to the pre-existing element at the end of the line
instead of adding a new element which will lose the style or font. Is
this really the correct approach?
I have three more questions in this context:
1) The para
I have to correct point 3) a little. In an e-mail with different fonts,
colours, bold, italics, clicking in the editor does communicate
something back to Thunderbird so it can update it's controls; or maybe
the editor just sets some "global" variables, that can be queried in the
UI.
--
You receiv
Thank you for your detailed answer which clarifies a lot of things. I
will investigate the interaction between Thunderbird and the editor
further.
Re. your last comment:
> I _think_ to fix that part you need to get Thunderbird tell Gecko about how
> to format the new paragraph.
I tried with a i
@Ehsan from comment #30 ("I'd be curious to know, FWIW!"):
Turns out that the Thunderbird e-mail front end is one big JS/XUL application:
http://mxr.mozilla.org/comm-central/source/editor/ui/composer/content/editor.js
I haven't looked very much, but I can answer some questions. For example the
"
Sorry to trouble you again. I have some more questions to understand how
the architecture hangs together. Let me summarise the questions from the
previous posts here:
Where is the mouse click translated into identifying a node of the DOM tree?
Your answer was nsFrame::HandlePress. I looked through
Thank you for your continued patience.
It is true that this bug is is about losing the font when clicking at the end
of the line after clicking somewhere else. However, I'd like to consider other
occasions where the font is lost, that is after inserting an image by paste.
Let's deal with this "o
Without a working font indicator it is impossible to tell what's going
on. So fixing bug 1139524 first.
Further testing over in the other bug showed that by clicking at the end
of the line sometimes the font in the next line is activated rather then
the one of the line being clicked.
--
You rece
Just noticed: Not only the font gets lost, also the font size can get
lost. For example when replying to a message in a small font, the size
gets bigger when clicking at the end after correcting something in the
same line.
--
You received this bug notification because you are a member of Ubuntu
B
Coming back to the suggestion from comment #25 and looking in
nsFrame::HandlePress.
I traced it down into ns[Text]Frame::GetChildFrameContainingOffset with
a call stack of:
nsFrame::GetChildFrameContainingOffset *or*
nsTextFrame::GetChildFrameContainingOffset
nsFrameSelection::GetFrameForNodeOffs
I'm working on it, but I can mostly do the debugging. Now I need some help to
actually fix the problem. If I can get that help, I can assign it to myself.
Otherwise, it might wait another 10 years ;-((
Note: The predecessor bug 250539 is from 2004.
--
You received this bug notification because
c/left/right/g ;-)
It varies whether nsFrame::GetChildFrameContainingOffset or
nsTextFrame::GetChildFrameContainingOffset is being called depending on
whether you click on the text, but almost to the *right* of the text, or
completely to the *right* of the text.
--
You received this bug notifica
The problem with losing the style after inserting an image (see comment
#14) has been moved to bug 1140617.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
composer changes font mid emai
Simple test using Midas: http://www-
archive.mozilla.org/editor/midasdemo/
1) type two lines, like shown:
one
two
They are shown in Times.
2) select first line and make it arial, select second and make it
courier
3) Click after the word "one" in the first line and type. Typing happens
in Times.
Maybe better to look further up in call stack, for example
PresShell::HandlePositionedEvent.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
composer changes font mid email
To manage no
Oops, after a refresh of my source, behaviour of nsFrame::HandlePress has
changed, now returns early:
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#2816.
Behaviour hasn't changed though. Click "far" left, font changes, click
left/on, font is correct.
--
You received t
Created attachment 8574843
Stripped down Midas demo, also alerts on clicks and dumps out info
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
composer changes font mid email
To manage n
Sadly I don't understand some of what you wrote. Let me see what I
understood.
You're saying you want to check how other rendering engines behave. I
ran the test from comment #37 on Chrome and IE. Both continue text entry
with the font present on the first line, so their behaviour is what I
would
Created attachment 8575104
Alternate test, much simpler
Here is a much simplified test "alternate.htm". Results:
FF: DIV, wrong font
IE: DIV, correct font
Chrome and Opera: #text, correct font.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
More results:
Safari (5.1.7, had it on some old machine): Same behaviour as Chrome.
Opera (27.0, fresh install): Same behaviour as Chrome.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
Please confirm that you are happy to change FF's behaviour to be like
Chrome, Opera and Safari.
I read the last section of your comment (quote: "... Good luck!") as a
confirmation, but before you were rather careful saying (1):
> If they all agree on putting the selection where I described above
I've done a little debugging.
On every mouse move event we get this:
>>> Entering PresShell::HandleEvent, frame=06EA9488
PresShell::HandleEvent calling nsLayoutUtils::GetEventCoordinatesRelativeTo
PresShell::HandleEvent calling FindFrameTargetedByInputEvent
PresShell::HandleEvent assigning frame
Created attachment 8576184
Alternate test, take 2, dumping out more info
Results:
FF: start=DIV(2) - end=DIV(2)
IE 10 and 11 (current): start=DIV(2) - end=DIV(2)
Chrome 41 (current): start=#text(10) - end=#text(10)
Opera 28 (current): start=#text(10) - end=#text(10)
Safari 5.1.7 (old): start=#text
It's not going past static FrameTarget GetSelectionClosestFrameForLine ()
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#3540
... nor static FrameTarget GetSelectionClosestFrameForBlock nor static
FrameTarget GetSelectionClosestFrame.
Also, very little processing in nsFr
Created attachment 8576320
A more comprehensive text
The more conservative approach would be not to change the selection
behaviour but to maintain/re-establish the correct "type in state" after
the click. That is what IE does: The DIV is selected, but typing
continues in the "correct" font, see co
Any idea why TypeInState::NotifySelectionChanged is never called when clicking
around in a ?
http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/TypeInState.cpp#75
Is that not a listener to listen to the selection changing? Maybe that
has something to do with our problem(s) (thinking a
You are correct, I was in "e10s" mode and there was another process
"plugin-container". Now I switched that off. I had noticed that my
debugging had become strange, but couldn't figure out why. So thank you!
Before considering changing the selection behaviour, I'd like to repeat
my question, but I
Created attachment 8576888
three line change to fix a 10 y/o problem ;-)
Skipping brFrames when determining the closest frame in a line. Can only
skip if the brFrame isn't the only selectable non-empty frame in the
line. Otherwise one couldn't click in that line at all.
Need to be careful since r
Sorry, you need to help me out here. Never done it before.
I will get the access rights as discussed on IRC.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
composer changes font mid ema
When you have a minute, could you please look at the results or instruct
me, how to interpret them.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
composer changes font mid email
To ma
@Aryeh: Yor comment really surprises me given the following:
In comment #68 Ehsan said:
> Good start, but this is still *far* from being ready for review.
In comment #60 Ehsan said:
> This affects more than just Thunderbird, and concerns behavior that is
> visible to Web pages.
> Web content ca
Thanks for the suggestions made in comment #78. I'm testing with
foo bar on the same
line
foo bar on the same
line
foo bar on the same line
This is strikethrough
25 m2
H2SO4
and some underline
foobar
Moving around with the cursor already works with the current version of
FF, including moving fr
Created attachment 8582360
Patch to fix all three problems: Click, "end" key, left arrow from start of
previous line
Can you please push this to the try server for me and tell me the exact steps
to do it. I was reading
https://wiki.mozilla.org/ReleaseEngineering/TryServer#How_to_push_to_try and
Created attachment 8582014
four line change to fix a 10 y/o problem ;-)
Here's a new patch. This fixes click beyond end of line *and* "end" key.
Still open: Left arrow at the start of the subsequent line.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is sub
Created attachment 8582931
Unified patch (code + test changes) ready for next push to try.
Pushed to try server (thanks guys for the support!):
https://treeherder.mozilla.org/#/jobs?repo=try&revision=9782fa678cd1
Aryeh: Please help me review the results.
Actually, I followed what was suggested f
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from
comment #87)
> I realized that I forgot about another case that we need to test. br frames
> are not the only reason for a line ending, we can also get line breaks at
> block boundaries, for example: block 1new line
> hereblock
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment
#88)
> Nit: you don't need to mention bug numbers in comments. This information is
> available through hg/git blame.
There are many bug numbers in the code (including some that you entered for bug
596506), so this poli
Thanks, the "mach mochitest-chrome" worked, I will supply a fixed test
tomorrow (now after 12 AM here). I assume I can just push a "unified"
patch with the code and the updated tests to the try server.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
Created attachment 8582923
Easy fix for test due to new selection behaviour (move commands)
This is the last of the updated tests.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
compos
Created attachment 8582686
Easy fix for test due to new selection behaviour (layout/generic)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
composer changes font mid email
To manage no
These tests are a little mysterious. I wanted to look at
editor/libeditor/tests/test_selection_move_commands.xul first. Sadly
mach mochitest-plain editor/libeditor/tests/test_selection_move_commands.xul
doesn't work? I've run single tests before, but they weren't XUL files.
So I ran
mach mochites
Comment on attachment 8582686
Easy fix for test due to new selection behaviour (layout/generic)
This fixes the failed test in layout/generic. More to come.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bug
(In reply to :Aryeh Gregor from comment #84)
> A good try line to use by default for editor changes is:
> try: -b do -p all -u all[x64] -t none
OK, but how do I send the patch to the try server? I have my "level 1" access
rights and I believe SSH is set up correctly. I tried
hg push -f ssh://mo
Created attachment 8582633
Patch to fix all three problems: Click, "end" key, left arrow from start of
previous line (updated coding style)
Here's the updated code according to the review.
I will review the test failures next.
--
You received this bug notification because you are a member of Ub
Is it worth running it on other systems as well since I found some -
most likely unrelated - problems (see comment #97) when running it
locally on Windows 7? Or are these known problems that always fail?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subsc
Created attachment 8582701
Easy fix for test due to new selection behaviour (richtext2)
Removed tests which now no longer fail due to changed selection
behaviour.
I'd appreciate some help with the stuff from comment #97:
How do I run test_selection_move_commands.xul separately and what do I make
Created attachment 8583259
Test case
Here is the test case. Forgive me if the JS is bad, I've never written any,
just copied bits and pieces around.
Two questions:
Where in the mochitest.ini do I put my new test? I put it right at the front
since I don't understand the syntax of "skip-if". Does
I'll revise the test and post a new one in a second.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
composer changes font mid email
To manage notifications about this bug go to:
https:
Created attachment 8583354
Test case (revised)
If this is good to go, I'll submit another "unified" patch (code + all
tests), if necessary.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
Created attachment 8584346
Unified patch (code + test changes + twice revised new test)
Thank you very much for the review and all the additional explanation.
I hope I could address your questions in additional comments in the test.
Sadly switching from "mousedown/up" to "click" as you had sugges
Created attachment 8584639
Unified patch (code + test changes + four times revised new test)
This should be good to go then ;-)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/584632
Title:
composer
Created attachment 8584608
Unified patch (code + test changes + three times revised new test)
Here comes the updated test. This time with some additional inline
elements.
I'm not sure why the second test should be wrong, I'll add another
attachment in a second to convince you ;-)
--
You receive
(In reply to Charles from comment #124)
IMHO the problem is in the coupling between TB and FF. I think it's
quite reasonable that the FF people are more conservative. Who would
want to break a browser with a big market share.
TB on the other hand is client software. An nothing should stop client
(In reply to Charles from comment #121)
> Are you seriously saying that this bugfix will NOT land in time for TB 38?
> Meaning, we will have to another full YEAR to see it fixed?
Given that the version spacing is six weeks we get 6 * (45-38) = 42 weeks,
that's 10 months ;-)
However, everyone is
Created attachment 8584620
Here comes another manual test.
Here some HTML to run a test by hand.
If clicking behind any of the eight lines in this test, "DIV" will be
returned in the current version of FF.
With the new behaviour clicking behind lines 1-6 and 8, "#text" will be
returned, but for
(In reply to maybe-the-one from comment #135)
> Personally, I never understood why this problem involved browsers at all.
That you don't understand the facts doesn't change them ;-)
Let me explain: Thunderbird is client software that sits on top of
Mozilla core software. The so-called "editor"
Created attachment 8515218
composition font also lost after insertion of image.
Composition font is also lost after inserting an image in a new message.
Watch the enclosed video. I am using these settings:
Options: Display, Formatting, Default Font: Arial.
Options: Composition, HTML, Font: Fixed w
Created attachment 8515199
Two videos showing the problem.
Here are two cases to reproduce the problem.
CASE 1:
===
Step 1:
Set the following options:
Options: Display, Formatting, Default Font: Script
Options: Composition, HTMl, Font: Batang
Step 2:
Reply to an e-mail written in Arial. Sta
(In reply to :Aryeh Gregor from comment #16)
> Unfortunately, we have no one actively working on the editor component, so
> basically all editor bugs on indefinitely on hold. Occasionally one or two
> gets fixed here or there, but as things stand, I wouldn't count on it.
OK, when you say "editor"
>From Bug 250539
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!, PTO
11/3-11/21) from comment #196)
2010-08-25 07:18:58 PDT
> It appears to me that this is an editor bug. If someone can create a test
> case as an HTML file and file a bug in Core::Editor, I may try to sneak a
>
Please land for ESR31.
One question: Landing this on 35 (comment #43 and comment #44) means that we
will see it in beta 36 one day soon now?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1360086
Titl
Since the fix to bug 1043310 (and therefore bug 1107844) has landed for
ESR31, this fix should probably be put back in for ESR31, right, Magnus?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1360086
T
Can this bug be resolved? I was fixed in Oct. 2013.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1229172
Title:
Thunderbird "Spell check as you type" stopped working after update to
1:24.0+build1
This bug is about a fault in TB v 24 which was fixed in 24.0.1.
The error was that inline spell-checking didn't not work at all.
The effect that you're observing is a different bug that I have reported
in bug 1100966.
Once again: Please close this bug.
--
You received this bug notification beca
@al...@yahoo.com: Please resolve the bug.
There are too many inactive bugs in the system with unknown state dangling
around for years.
This bug is resolved, it should be marked resolved.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu
@al...@yahoo.com: Please resolve the bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1229172
Title:
Thunderbird "Spell check as you type" stopped working after update to
1:24.0+build1-0ubuntu0.
66 matches
Mail list logo
