Closed
Bug 98564
Opened 23 years ago
Closed 20 years ago
caret overlaps the last character in textfield (if positioned after the last char)
Categories
(Core :: DOM: Editor, defect, P3)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
mozilla1.5beta
People
(Reporter: sujay, Assigned: kinmoz)
References
Details
(4 keywords, Whiteboard: [caret][QAHP] EDITORBASE+ edt_x3)
Attachments
(3 files, 2 obsolete files)
705 bytes,
text/html
|
Details | |
3.38 KB,
patch
|
smontagu
:
review+
sfraser_bugs
:
superreview+
|
Details | Diff | Splinter Review |
13.66 KB,
image/jpeg
|
Details |
build:2000081105m18 Dunno if this should go in Themes component or Editor. Pls reassign if incorrect. Steps: 1. Switch theme from modern to classic from under the prefs dialog. 2. Type some url, say, www.yahoo.com in the url textfield 3. Observe that the cursor blinks right on top of the last character's right border making it somewhat unreadable. This does not happen under modern skin or 4.x browser. ------- Additional Comments From beppe@netscape.com 2000-08-11 15:10 ------- moving this to m19, will see if our intern can take a look at this one ------- Additional Comments From Ryan Cassin 2000-08-11 15:17 ------- I'll take a look at this one ------- Additional Comments From Ryan Cassin 2000-08-13 08:44 ------- This bug belongs in the Themes component because the issue isn't confined to the Editor. Any text field throughout Mozilla has this issue. ------- Additional Comments From leger@netscape.com 2000-08-17 12:38 ------- Adding classic keyword ------- Additional Comments From Michael Kaply 2001-02-12 10:06 ------- I don't believe this is Classic only. In Modern, If I put a lowercase "L" in the URL bar, the lowercase l blinks as the cursor. This is a general problem. ------- Additional Comments From Michael Kaply 2001-02-12 10:06 ------- *** Bug 64499 has been marked as a duplicate of this bug. *** ------- Additional Comments From achimha@innotek.de 2001-02-12 10:11 ------- I can confirm it in Modern. Go to Search -> Find in this page -> enter the letter "l" and you will see it overlap with the I beam cursor. ------- Additional Comments From shrirang khanzode 2001-03-21 08:36 ------- *** Bug 72778 has been marked as a duplicate of this bug. *** ------- Additional Comments From sujay@netscape.com 2001-03-21 08:39 ------- Lets set a target milestone for this bug....so we don't see this problem in modern theme? ------- Additional Comments From shrirang khanzode 2001-03-21 08:40 ------- it's everywhere..it's a general problem ------- Additional Comments From sujay@netscape.com 2001-03-21 08:57 ------- Okay 3 things on this bug: 1) Its not a themes bug, because its happening under both themes. So I'm changing it back to Editor 2) This bug was assigned to a summer intern who is no longer here, and he didn't take care of it, so I'm changing it back to "beppe" as the Assigned To. 3) We need a target milestone for this bug. ------- Additional Comments From sujay@netscape.com 2001-03-21 09:01 ------- changing summary. ------- Additional Comments From sujay@netscape.com 2001-03-21 10:11 ------- oops, ignore my comment about summer intern below...actually Ryan is still working for mozilla now....adding him back to Cc: list.. Ryan, whats the status on this bug ? thanks! ------- Additional Comments From Ryan Cassin 2001-03-21 14:28 ------- Under any Mozilla dialog box in both the Modern and Classic themes, this bug is no longer valid. In any URL field or find dialog the "m" in www.yahoo.com is no longer overlapped by the cursor. However in normal text entry in the editor (in the body of a document) the cursor overlaps the text (for example, the "m" in www.yahoo.com is overlapped) I think we should mark this bug WORKSFORME and open a new one which explains this problem. ------- Additional Comments From shrirang khanzode 2001-03-21 14:33 ------- i had mentioned that the 'right border of the last character is getting overlapped by the caret', which is still happening clearly. ------- Additional Comments From sujay@netscape.com 2001-03-21 14:40 ------- Lets not mark this bug WORKSFORME, we all are still seeing the original problem. ------- Additional Comments From selmer@netscape.com 2001-03-22 06:45 ------- Ryan, the exact problem described in the summary of this bug still happens. As noted, it also happens in other places (prompting me to file bug 72778 which was duped against this bug.) Can you update the bug's status and milestone? If this isn't happening before beta, I need to see if it's priority should be raised. Thx, Steve ------- Additional Comments From beppe@netscape.com 2001-03-29 15:23 ------- assigning to Simon to take a look at ------- Additional Comments From Simon Fraser 2001-04-11 18:52 ------- When the caret is 1 pixel wide, as it is for the URL bar and all single line text widgets, it shows in exactly the same location as it does in Wordpad, with similar font settings. When at the end of the line, it only overlaps the last character if that character slopes to the right (e.g. a '/'); a lower case 'L' is not obscured. When the caret is 2 pixels wide, as it is for Composer, then some character overlap occurs, but not to the extent that it impairs usability. If you disagree, please reopen, but be sure to state the exact conditions under which this overlap occurs. ------- Additional Comments From Simon Fraser 2001-04-11 19:07 ------- Note that bug 64276 also covers this issue. ------- Additional Comments From selmer@netscape.com 2001-04-12 10:47 ------- Reopening since there was no fix and the problem still exists. Perhaps you'd rather have 72778 reopened instead, but I'm reopening this since 72778 was dup'd here. To easily reproduce this behavior in the 4/11 04 build, goto mail, hit the NewMsg button, type a single lower case 'j' in the first address field and then watch it blink down to 2 or 3 pixels with the input cursor. The letter 'j' does *not* slope to the right, but is almost entirely obscured. Now, do this exact same thing in 4.x. You'll find a very nice noticable gap between the entire letter 'j' and the input cursor. Marking 4xp. Hmmm. The fonts are very different for some reason. The 'j' in the 6.x mail addr widget does not have the horizontal bar at the top. Also, adding a letter after the 'j' and then using the arrow keys to go back and forth positions the input cursor differently than just typing the 'j' by itself. This is also different from 4.x where the input cursor always goes back to the original spot. It may be that this whole bug is about the input cursor being off by 1 pixel during *text input*. ------- Additional Comments From Simon Fraser 2001-04-12 12:04 ------- *** Bug 64276 has been marked as a duplicate of this bug. *** ------- Additional Comments From Simon Fraser 2001-04-12 12:06 ------- What's odd is that on my NT box, the caret position is the same on 4.x and Mozilla. On shrir's NT box, I do see the caret overlap, which I agree is bad. This is going to turn out to be dependent on nasty rounding errors and font metric differences, I think. I'll see what I can do. ------- Additional Comments From Simon Fraser 2001-04-14 22:48 ------- *** Bug 76076 has been marked as a duplicate of this bug. *** ------- Additional Comments From Simon Fraser 2001-04-14 22:49 ------- Comment from jrgm in bug 76076: There is a dependence on the font for this. At the end of a line, the position is correct for the default serif font, and off to the left by one for sans-serif and monospace for my win2k system. On Mac, serif and sans-serif are off, but monospace is ok (I think; didn't have a magnifier handy on Mac). But then when it is in the middle of a line, on win2k, serif is off by one to the right, while monospace and sans-serif exactly split the characters. (and mac, is monospace off by one, and serif and sans-serif OK). ------- Additional Comments From scalkins@netscape.com 2001-04-17 16:57 ------- This affects IM Compose as well setting Mostfreq keyword also ------- Additional Comments From gail@netscape.com 2001-04-17 17:46 ------- Created an attachment (id=31248) extreeme close-up. ------- Additional Comments From Jesse Ruderman 2001-04-17 18:47 ------- That screenshot seems to show the opposite problem: the caret overlaps with the character to the *right* when it's in the middle of text. I think the caret is in the correct place when it's in the middle of text; it's just too thick. In bug 39529 it looks like some Composer people decided that the caret should be two pixels thick in Composer but one pixel thick in the location bar. Anyway, I think that's a separate problem. If you file a new bug for that problem, please mention the bug number here. ------- Additional Comments From Jesse Ruderman 2001-04-17 18:48 ------- From dup bug 76076, this is for all textfields, not just the location bar. Updating summary. ------- Additional Comments From Gervase Markham 2001-04-18 03:31 ------- Not even close to mostfreq (although still _very_ annoying.) You need around 10 dupes, and this has two. But, while I'm here, could I put a vote in for this being fixed as soon as possible? :-) Gerv ------- Additional Comments From selmer@netscape.com 2001-04-19 23:49 ------- Jesse, Gail's image shows just one way this manifests. The overlap problem varies depending on what you've done so far. If you're entering text then it overlaps the last character. If you cursor around, then it seems to get off track and can show up like the attached image. ------- Additional Comments From John Morrison 2001-04-27 16:21 ------- *** Bug 77952 has been marked as a duplicate of this bug. *** ------- Additional Comments From beppe@netscape.com 2001-05-03 14:19 ------- moving to 1.0 per triage meeting, still reproducible, but not impacting funcitonality ------- Additional Comments From brade@netscape.com 2001-05-08 08:37 ------- *** Bug 79405 has been marked as a duplicate of this bug. *** ------- Additional Comments From gail@netscape.com 2001-05-29 13:54 ------- This really needs to get fixed. Anybody working on this? ------- Additional Comments From Anatoliy Averbukh 2001-06-08 09:43 ------- I think, I have found exact conditions, when overlap arises. In fact, it is not just problem with last character (changing summary). It happens for all characters for any character position for just SMALL size and VARIABLE width fonts. If we use font with bigger size or fixed one, there is NO problem at all. However, for SMALL and VARIABLE font size, the problem persists. Unfortunately, default font size for all editor applications (including and composer itself) is small enough and VARIABLE, and so users can watch the overlap (that really little thing could confuse them). I agree with Simon, it happened, because caret width for small fonts is big enough for those small and variable fonts. One pixel wide caret (instead of 2 pixels, as it is today) would be OK for that, and could solve the problem (including and corresponding bugscape bug, this bug blocks it). Is it possible to fix that for m0.9.2? New summary would be: CARET OVERLAPS IN TEXTFIELDS FOR SMALL SIZE AND VARIABLE FONTS ------- Additional Comments From Simon Fraser 2001-06-11 11:45 ------- This blocks a bugscape (4673) bug which is 0.9.2 ------- Additional Comments From Simon Fraser 2001-06-11 14:30 ------- Can someone please give me a specific font/size combination for which they see poor caret positioning, on an NT box? Things look fine to me, even using small font sizes in Times New Roman. A testcase document would be good. ------- Additional Comments From Anatoliy Averbukh 2001-06-11 15:43 ------- From prefs: Proportional = Serif Serif = Times New Roman, size 16 From Format menu: font = Variable Width (just for variable, for Fixed font, all is OK), size = medium ------- Additional Comments From Simon Fraser 2001-06-11 17:25 ------- I figured out why this is happening. Some code I added to keep the caret within the text frame (to avoid caret turds) is pushing the caret to the left when it's at the end of a frame. So we need to figure out how to draw the caret anywhere we like, without leaving turds. That problem has plagued the caret all along...... ------- Additional Comments From Jesse Ruderman 2001-06-17 18:23 ------- *** Bug 86301 has been marked as a duplicate of this bug. *** ------- Additional Comments From Simon Fraser 2001-06-19 12:05 ------- Not gonna get to this by 0.9.2, alas. ------- Additional Comments From beppe@netscape.com 2001-06-27 11:22 ------- this is a risky fix for the current milestone, could intor lots of cruft, moving to 1.0 ------- Additional Comments From brade@netscape.com 2001-08-24 10:49 ------- *** Bug 96755 has been marked as a duplicate of this bug. *** ------- Additional Comments From brade@netscape.com 2001-08-24 10:53 ------- From another bug (comments from beppe): this was done so when the user is in a textarea or textfield, the caret is not lost under the edge of the box, in other cases the caret could end up outside the textframe which would result in caret cruft on the screen ------- Additional Comments From Madhur Bhatia 2001-08-24 12:15 ------- similar bug was bug 19180 ------- Additional Comments From selmer@netscape.com 2001-08-24 18:51 ------- responding to beppe's comment on 8/24: shouldn't the placement of the caret always be the same and instead truncate the number of characters shown in the field to ensure the caret *can't* fall in any of the bad places?
*** Bug 48602 has been marked as a duplicate of this bug. ***
Comment 2•23 years ago
|
||
Whups, running with that for a while I realized that Unix browsers don't
normally stop at punctuation by default (it makes life difficult in the urlbar)
even though many editors do. Added the following to unix.js:
Index: unix/unix.js
===================================================================
RCS file: /cvsroot/mozilla/modules/libpref/src/unix/unix.js,v
retrieving revision 3.49
diff -r3.49 unix.js
70a71,73
> // override double-click word selection behavior.
> pref("layout.word_select.stop_at_punctuation", false);
>
Comment 3•23 years ago
|
||
Sorry, wrong bug. I have no idea why that comment ended up in this bug.
Marking nsbeta1+ per syd. Need to fix for composer usability.
Keywords: nsbeta1+
Updated•23 years ago
|
Whiteboard: [caret][QAHP] EDITORBASE → [caret][QAHP] EDITORBASE-
*** Bug 107905 has been marked as a duplicate of this bug. ***
Agree, not EDITORBASE. Classic is not the default skin.
Whiteboard: [caret][QAHP] EDITORBASE- → [caret][QAHP]
This bug still exists, it's one of the oldest I know and one of the bugs that annoy me most. Currently I'm using Build ID 2002011908 (Win98) and the status of the bug is: It happens in the address bar, where the caret has a width of one pixel and it overlaps one pixel with the last character (e.g. i is overlapped as a whole in the address bar). It seems to always happen, regarless of what the last character is. It happens in every text area, where the caret has a width of two pixels and sometimes overlaps two pixel with the last character (e.g. in case of 'm'), sometimes only one pixel (in case of '/'), but sometimes not at all (in case of ')' or '.'). In text fields it sometimes also overlaps a character in the middle of a word. E.g. in case of 'ad' it will overlap the 'd' when being placed between a and d. That's probably because it has a width of two pixels. It also happens within single line text fields, where the caret has a width of one pixels, but for less characters. I thought this is one of the smaller ones that will get fixed very soon, but it's still there and even though it's a minor bug, it can sometimes make filing out forms really annoying.
Comment 8•23 years ago
|
||
*** Bug 114766 has been marked as a duplicate of this bug. ***
Comment 9•22 years ago
|
||
*** Bug 131922 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 10•22 years ago
|
||
*** Bug 132296 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 11•22 years ago
|
||
nominating EDITORBASE...this is already marked nsbeta1+
Whiteboard: [caret][QAHP] → [caret][QAHP] EDITORBASE
Comment 12•22 years ago
|
||
I won't have time for this. We know why it happens; because we push the caret back into the frame to avoid drawing turds. To fix this, we need to make sure that the caret can draw outside of frames without leaving turds (which would be a good thing to fix in general)
Assignee: sfraser → kin
Comment 13•22 years ago
|
||
EDITORBASE-, marking nsbeta1- per kmcclusk triage
Comment 14•22 years ago
|
||
*** Bug 145248 has been marked as a duplicate of this bug. ***
Comment 15•22 years ago
|
||
In Windows 2000, modern theme, the caret is one pixel wide and doesn't seem to obscure any characters to the left or right of it.
Comment 16•22 years ago
|
||
On my PC (Win98) the caret in the URL bar is also only one pixel wide and it still overlaps into the letters (either the one before or the one after it). It's only two pixels wide in a text box like the one I'm entering this text right now and the error happens on my PC regardless of theme. It's rather the font, font-style and font-size used that has an influence on this problem.
Comment 17•22 years ago
|
||
This is very dependent on the font used, and where the caret is. It needs toobe at the end of a frame to show the problem.
Comment 18•22 years ago
|
||
*** Bug 168071 has been marked as a duplicate of this bug. ***
Comment 19•21 years ago
|
||
topembed+, kin are you the right owner for this? Is there a particular test case we should be looking at?
Target Milestone: Future → mozilla1.4alpha
Comment 20•21 years ago
|
||
leaving topembed+, but I realize this is difficult and should be prioritized behind most other topembed+ bugs. In other words, something we do want to fix eventually.
Updated•21 years ago
|
Keywords: polish
QA Contact: sujay → beppe
Whiteboard: [caret][QAHP] EDITORBASE- → [caret][QAHP] EDITORBASE edt_x3
Comment 21•21 years ago
|
||
EDITORBASE+
Whiteboard: [caret][QAHP] EDITORBASE edt_x3 → [caret][QAHP] EDITORBASE+ edt_x3
Comment 22•21 years ago
|
||
using a current mozilla build, look at the attached test case. In the browser window, set the caret within the textareas and look at how the caret overwrites the characters, especially the w, m and t. Now select to edit the page and set the caret within the paragraph, the same overwrite occurs within the string. In either case, the caret placement is consistent.
Comment 23•21 years ago
|
||
test case that can be used
Comment 24•21 years ago
|
||
is this still on track for 1.5a?
Comment 25•21 years ago
|
||
*** Bug 196748 has been marked as a duplicate of this bug. ***
Comment 26•21 years ago
|
||
Kin, will start working on this starting tomorrow.
Assignee | ||
Comment 27•21 years ago
|
||
This patch makes things look a bit better. The caret will no longer overlap the last character on the line *unless* the last character on the line is right up against the edge of the content area, and there is no padding/margin between the last character and the edge of the content area.
Assignee | ||
Comment 28•21 years ago
|
||
I should also mention that I tested this patch with text widgets that were LTR (right and left aligned) and RTL (right and left aligned), and also composer.
Attachment #124856 -
Flags: superreview?(sfraser)
Attachment #124856 -
Flags: review?(smontagu)
Attachment #124856 -
Flags: superreview?(sfraser)
Attachment #124856 -
Flags: review?(smontagu)
Attachment #124856 -
Attachment is obsolete: true
Assignee | ||
Comment 29•21 years ago
|
||
After talking to smontagu on IRC we decided to also handle the case where the caret disappears when indenting a blank doc multiple times past the edge of the view port in Composer ... removing the checks for right alignment allows us to handle that case too. For reviewers: I am aware of the fact that I do the same calculation in both cases, but I thought that was ok for the sake of readability.
Attachment #125032 -
Flags: superreview?(sfraser)
Attachment #125032 -
Flags: review?(smontagu)
Assignee | ||
Comment 30•21 years ago
|
||
I should also mention that with the patch, I was surprised that we don't get any caret cruft like we used to. This may be due to some of the tweaking that's been going on over the last couple of milestones to reduce the number of times the caret draws, etc. In any case, I've tried this patch out on Win32 and MacOSX ... and the only caret cruft that I noticed was only reproduceable in MacOSX builds, and I could reproduce them without my fix so they are unrelated.
Comment 31•21 years ago
|
||
Comment on attachment 125032 [details] [diff] [review] Patch Rev 1.1 I like it. Much, much simpler, and it works. One nit: >+ if (caretRect.x == frameRect.x && caretRect.x <= clipXMost && >+ caretXMost > clipXMost) Please either put all the conditions on the same line or each one on a separate line. and one super-nit: why do you say the <br> is "about" 1 twip in width? I don't think having two conditions producing the same result improves readability , and the idea I suggested on IRC of combining the two conditions and interleaving with comments ends up looking even worse. I think my own preference would be for PRBool foo = <expr>; /* Comment block */ PRBool bar = <expr>; /* Comment block */ if (foo || bar) { caretRect.x = clipXMost - caretRect.width; } The disadvantage of that is that you are evaluating both expressions unnecessarily. Making each expression a #define would be a way round that, but is still a bit ugly. The bottom line is it's up to you :-) r=smontagu whatever you decide.
Attachment #125032 -
Flags: review?(smontagu) → review+
Updated•21 years ago
|
Attachment #125032 -
Flags: superreview?(sfraser) → superreview+
Comment 32•21 years ago
|
||
*** Bug 211635 has been marked as a duplicate of this bug. ***
Comment 33•21 years ago
|
||
*** Bug 136679 has been marked as a duplicate of this bug. ***
Comment 34•21 years ago
|
||
as it wasn't mentioned above, the bug shows up in firebird and thunderbird too. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030810 Mozilla Firebird/0.6.1+
Comment 35•21 years ago
|
||
Another duplicate of this bug found at http://bugzilla.mozilla.org/show_bug.cgi?id=150233
Comment 36•21 years ago
|
||
*** Bug 150233 has been marked as a duplicate of this bug. ***
Comment 37•21 years ago
|
||
as the patch has a review and a superreview and the target is still set to 1.5beta, are there any chances to get an approval for it?
Comment 38•21 years ago
|
||
Comment 39•21 years ago
|
||
Comment on attachment 130469 [details]
Example
Example of the caret overlap bug. The last letter is an "f". Note how the
caret overlaps it making typing "annoying".
Attachment #130469 -
Attachment description: screen capture of the caret overlap. The last letter is an "f". Note how the caret overlaps it making typing "annoying". → Example
Comment 40•21 years ago
|
||
A new target milestone needs to be set. Current target is 1.5 beta, but 1.5 final will arrive in a few days. Maybe 1.6 alpha as a new target?
Comment 41•21 years ago
|
||
looks like this patch has an r and an sr and we just need someone to drive it into the tree, yes? I can help with that if I'm reading things correctly.
Comment 42•21 years ago
|
||
your help would be highly appreciated. I, too, can't see any reason in this thread that would prevent this patch from being checked in. Maybe this bug was just forgotten. the final patch (rev. 1.1) is from 2003-06-05, that was three month ago. the bug was filed on 2001-09-06, so it is a really ancient bug.there is a r and a sr but nobody bothered to check it in up to now. it is a really nasty bug, because it is so obvious, especially in the mail client, because here it comes to "heavy typing".
Comment 43•21 years ago
|
||
I don't really want to spam bugzilla, but... Scott, didn't you succeed in driving the patch into the tree? Or, what keeps you from doing so? And why could nobody answer my former questions? I'm not annoyed by the fact that the patch isn't checked in yet, but the fact that no reasons are given for it.
Comment 45•21 years ago
|
||
Good news for all those people that want this bug to be fixed. MadmanNova includes the revied and superrevied patch in his current Firebird builds (MadmanNova is known to include MNG support there as well, so his builds show what MozillaFirebird can be). the thread: http://forums.mozillazine.org/viewtopic.php?p=264972#264972 link to a current build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031116 Firebird/0.7+ (18hr - Mike Tigas (Nova); MNG,DOMi,Venkman; OxG6;)): http://www.missouri.edu/~msa0288/MozillaBuild/MozillaFirebird-MNG-DOMi-Venkman.exe
Comment 46•21 years ago
|
||
Folks, sorry for the delay in getting this checked in. It fell off the radar. I just checked this in tonight. It will be in Mozilla 1.5beta and the next Thunderbird release.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Updated•21 years ago
|
Flags: blocking1.6b?
Comment 47•21 years ago
|
||
This bug is also in Thunderbird. Does this bug report cover that or is a separate report required, and if so, will this fix also resolve the bug in Thunderbird?
Comment 48•21 years ago
|
||
core bug fixes always fix both. Thunderbird is built from the same tree as mozilla mail.
Comment 49•21 years ago
|
||
Looks like this bug caused a regression: http://bugzilla.mozilla.org/show_bug.cgi?id=226325
Comment 50•21 years ago
|
||
this was backed out of 1.6b because of the regression it caused in: Bug #226325
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 51•21 years ago
|
||
Even when the patch worked, it wasn't all that great. I think the cursor should just look exactly like it does in a text box (input type="text"). That cursor is much thinner and also well-placed.
Comment 52•21 years ago
|
||
No, not this bug again. Beside the non collapsing dropdown list, this is the most noticable and annoying mozilla bug ever!!! I can't believe that the regression mentioned above is that noticable, because I never noticed it myself. Now it's there in thunderbird and firebird again. *sigh* I have waited for this fix for years and now...
Comment 53•21 years ago
|
||
ok, for all those firebird users that hate this bug as much as I do: Kindly enough Mike Tigas (MadmanNova) bundles his alternative Firebird MNG nightlies with the caret patch (rev. 1.1) again. Please note, that the mentioned patch causes a regression (which will show up only in rare real life situations, whereas the original problem shows up all the time - just my humble opinion ;) ), but it should do its work until a bugfixed patch is written. See the specific thread: http://forums.mozillazine.org/viewtopic.php?t=36797&start=45 Download here: http://www.missouri.edu/~msa0288/MozillaBuild/
Comment 54•21 years ago
|
||
Unfortunately, the patch in MadmanNova's build only "solves" the problem in the browser and not in the mail client, which is where it is most visible. Is there a patched version of Thunderbird out there? Is there any update on when this "might" be fixed for good? This is the most annoying bug.
Updated•21 years ago
|
Flags: blocking1.6? → blocking1.6-
Comment 55•21 years ago
|
||
*** Bug 229304 has been marked as a duplicate of this bug. ***
Comment 56•21 years ago
|
||
@ Edward Maloney: The patch was checked into the trunk for some days. I kept one of the thunderbird builds from these days (20031126 actually), that worked fine for me (in any aspect). I hope, that kinmoz@netscape.com succeeds in updating the patch again, so it can checked into the trunk again. Maybe just a simple additional check is needed...
Comment 57•20 years ago
|
||
*** Bug 238629 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking1.7?
Flags: blocking1.7-
Flags: blocking1.6-
Comment 58•20 years ago
|
||
Help. As this bug has been annoying me a lot for quite some time, I started creating firefox builds for myself and manually merging this patch into the source code. It all worked fine until May 12th when I successfully created a Firefox build the last time (available here: http://forums.mozillazine.org/viewtopic.php?t=71859 ). But I tried again 2 times ago, it compiled but completely messed up the firefox layout (the thunderbird one, too). Some icons were just garbage, and the text in the url and google bar didn't fit. Does any have an assumption, what checkin (between May 12th and 30th) can have caused this behaviour? Many thanks in advance.
Comment 59•20 years ago
|
||
I attached a picture of the garbage, that shows up when applying the modified nsCaret.cpp to the source now. Note that even the page rendering is messed up.
Comment 60•20 years ago
|
||
Not much to add here because I'm not a programmer, but as a user, I absolutely cannot believe that this bug, common to each and every Mozilla product, still has yet to be fixed since the summer of 2000. What do user have to do to help move this up the priority list? It's one of the most annoying bugs and it's been around for far too long. Being common to each Mozilla product, I'm really surprised that it hasn't been fixed yet.
Comment 61•20 years ago
|
||
Not much to add here because I'm not a programmer, but as a user, I absolutely cannot believe that this bug, common to each and every Mozilla product, still has yet to be fixed since the summer of 2000. What do user have to do to help move this up the priority list? It's one of the most annoying bugs and it's been around for far too long. Being common to each Mozilla product, I'm really surprised that it hasn't been fixed yet.
Comment 62•20 years ago
|
||
Anyone here who can help? (see comment #58/#59). I am sure that I have to exchange one file with an older revision. Which updated file may cause the layout garbage?
Comment 63•20 years ago
|
||
Comment on attachment 149791 [details]
Obsolete
The garbage was NOT caused by application of this patch. But I didn't figure
that out :(
Sorry for spamming this thread.
Attachment #149791 -
Attachment is obsolete: true
Comment 64•20 years ago
|
||
Comment on attachment 149791 [details]
Obsolete
The garbage was NOT caused by application of this patch. But I didn't figure
that out :(
Sorry for spamming this thread.
Attachment #149791 -
Attachment description: Picture that shows the garbage when applying Rev. 1.1 now. → Obsolete
Comment 65•20 years ago
|
||
This bug is now appearing in Firefox 0.9. See comments thread Bug#: 238629 I thought that because the resolution box indicated that the bug was resolved that it actually was. I guess it has not been resolved.
Comment 66•20 years ago
|
||
WHEN WILL THIS BUG FINALLY BE FIXED???? If i would be a c-programmer, i'd do it, but please, it's a killer for some of my customers to switch from Bill's products to Mozilla's...
Comment 67•20 years ago
|
||
Maybe advertise to vote for this bug in the mozillazine forums. I regularily build Win32 builds with the Patch (rev. 1.1) manually applied. I know that this will introduce the regression, but in my eyes it is better to have a regression sometimes than a bug always. Get my builds at pryan.org: http://www.pryan.org/mozilla/firefox/amano/
Comment 68•20 years ago
|
||
Will this bug ever be fixed? I want to use ThunderBird but can not just because of this bug. I am a visual typist, i.e., I need to see what I am typing to get my feedback and this bug disallows me to do that. I really want to get rid of O.E. as my mail client and adopt ThunderBird. Please do something about it.
Comment 69•20 years ago
|
||
over hill, over dale, we will hit the dusty trail... all the editor:core folks are off doing other stuff, folks. such is the nature of layoffs.
Comment 70•20 years ago
|
||
@ Joe Francis looks like the got lost on the dusty trail with this one... ;-) PS: i'm aware that the developer have other things to do too where they get payed. And yet, since 2001 ... ;-) Maybe one should change the target milestone in this bug from mozilla 1.5beta to 1.7.2-and-a-half?! Not aiming to spam this bug, just to reactivate attention on it.... happy 'puting
Comment 71•20 years ago
|
||
(In reply to comment #70) > Not aiming to spam this bug, just to reactivate attention on it.... > happy 'puting It's driving me nuts too - the one thing that's stopping me making the switch from OE to Thunderbird, and still very annoying in Firefox.
Comment 72•20 years ago
|
||
*** Bug 258268 has been marked as a duplicate of this bug. ***
Comment 73•20 years ago
|
||
(In reply to comment #71) yeah, it must be really a verrrry difficult task, to add 1 (in words one) to the positioning counter for the caret at the right place in the right module. we assume x as the positioning pointer for the caret: x = x + 1, or in good old c: x++. Hmmm... else, since i'm an old fashioned programmer (assembler, cobol on OS390), knowing nothing about object oriented and all that fancy stuff: if modern programming is that complex, then i don't know, how it's gonne be in 10 years.... ;-) I guess, we ought to be just lucky to get displayed something on the screen.... ;-))) No offense, just a bit humor, ok?!
Comment 74•20 years ago
|
||
So there isn't any solution of this problem, that have annoying people since 2000! :) Well, I've noticed that the caret is 2px wide in a textbox i.e, but not in the URL bar. So, I wonder if there is any way that I can change the caret to 1px overall in the browser? A value in about:config or something? I use Firefox 0.9.3.
Comment 75•20 years ago
|
||
Setting the blocking Firefox 1.0 flag since this is the last remaining highly visible glitch in Firefox (after having the non collapsing URL bar fixed). Reasons: - High visibility (you see it every time) - Low usability (sometimes it is hard to disinguish if letters have been pressed or not and sometimes you might confuse letters with others) - The last issue that lets you easily distinguish between chrome windows and "true" windows.
Flags: blocking-aviary1.0?
Comment 76•20 years ago
|
||
Note that this bug is common to the Mozilla suite, Firefox and Thunderbird. Resolving it within one program should be checked to see if it resolves the issue on the others at the same time.
Comment 77•20 years ago
|
||
we would need a well tested patch at this point to consider for 1.0. if one appears please renominate.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Comment 78•20 years ago
|
||
Out of curiosity I compiled a thunderbird with the changes of patch rev. 1.0 applied. The regression happened here as well (rather worse, but maybe that's my imagination). From this I can conclude that only one of those code lines will cause the regression, that both patch revisions have in common. Maybe this bug is in need of a new bug owner, since kinmoz@netscape.net didn't reply to any subjects in this bugzilla thread since June 2003. Maybe this should be assigned to smontagu@smontagu.org since he had a look at this stuff already.
Comment 79•20 years ago
|
||
To push Firefox and Thunderbird in the internet is one thing (which i totally support), to fix such an obvious and obnoxious bug is a total different thing and should be done, NOW! Hey, you, who is in charge of this, wake up!!! People considering of switching away from IE want to see a clean product, not only inside, where they can't see, but also on the outside, where they can see!
Comment 80•20 years ago
|
||
Lukas Wymann, before commenting on bugs, please read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html Thanks, Prog.
Comment 81•20 years ago
|
||
(In reply to comment #80) > Lukas Wymann, before commenting on bugs, please read > http://bugzilla.mozilla.org/page.cgi?id=etiquette.html > > Thanks, > > Prog. Oh, how good, that some people know at least how to behave unlike me. And others don't know how to fix bugs, unfortunately, since ... ehhmmm, when was this opened? Sometimes in the year 2001 with first comments already a year before?! I'm sorry, but you're targeting the wrong guy with this link!
Comment 82•20 years ago
|
||
Well, I applied patch "Patch Rev 1.1" to my trunnk (1.8a) debug build. I couldn't reproduce bug 226325 after that with the testcase attached in that bug. Then I backed out the patch for bug 216101 and after that I could reproduce bug 226325.
Depends on: 226325
Comment 83•20 years ago
|
||
Rescued from the mailbox that catches our bounces: (for future reference, you need to click the link at the top of the bugmail, and add your comment using the form on the web page) Date: Wed, 27 Oct 2004 14:47:00 +0200 From: dumbone <dumbone@greenmail.ch> To: bugzilla-daemon@mozilla.org Subject: Re: [Bug 98564] caret overlaps the last character in textfield (if positioned after the last char) >Well, I applied patch "Patch Rev 1.1" to my trunnk (1.8a) debug build. >I couldn't reproduce bug 226325 after that with the testcase attached in that bug. >Then I backed out the patch for bug 216101 and after that I could reproduce bug >226325. Hi Thanks for the suggestion. Did you test also the regression-bug, leaving a drawn caret to the right of the newly blinking caret, when you backspace at the wrong moment? Regards, and Thanks, Lukas
Comment 84•20 years ago
|
||
(In reply to comment #83) > Thanks for the suggestion. Did you test also the regression-bug, leaving > a drawn caret to the right of the newly blinking caret, when you > backspace at the wrong moment? Well, that's what I meant with bug 226325 (the regression-bug). Or is there another regression that was caused by fixing this bug?
Comment 85•20 years ago
|
||
Hurray. Wonders happen ;) TEST BUILD: I manually applied the patch for bug 216101 to the current Fx RC2 sourcecode and everything works well. The garbled stuff when pressing backwards can't be seen anymore. A test compile to see how well it works can be found here: http://www.pryan.org/mozilla/firefox/amano/Fx-1.0RC2-O1-Gopher-MNG-Exp.exe BRANCH APPROVAL: I know, that it is late in the game, but since chofman explicitly asked to renominate this bug for 1.0 when a patch appeared I do so (especially since this is a highly visible bug, common to all Mozilla products for ages). To solve this bug a branch checkin of the patch for bug 216101 ( https://bugzilla.mozilla.org/attachment.cgi?id=151657&action=view ) would be needed as well (both patches have a review and a superreview). TRUNK checkin/Thunderbird: @Scott McGregor: Can you help again to check this into the trunk. Since the fix for bug 216101 landed on the trunk already, it should work like a charm now. Since thunderbird is more affected by this bug, you might want to land both patches ( https://bugzilla.mozilla.org/attachment.cgi?id=125032&action=view and https://bugzilla.mozilla.org/attachment.cgi?id=151657&action=view ) on the branch for Thunderbird 1.0 as well.
Flags: blocking-aviary1.0- → blocking-aviary1.0?
Updated•20 years ago
|
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Comment 86•20 years ago
|
||
(In reply to comment #85) > Hurray. Wonders happen ;) > Ditto! As far as my testings with this build from Bernd and my eyes go, it seems to me that it got solved; the overlap-issue and the regression as well. THANK YOU THANK YOU THANK YOU ! :-)
Comment 87•20 years ago
|
||
ok guys. I need help testing this on the aviary 1.0 thunderbird builds. I just put both patches there and could really use testing coverage for caret regressions! I also just checked this fix back into the trunk (*again*) since it looks like 216101 fixes the caret fragment regressions this patch introduces.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Keywords: fixed-aviary1.0
Comment 88•20 years ago
|
||
in TB version 0.9+ (20041110) looks ok everywhere expect the actually message body when typing a new email or replying to an email. In the search bar, subject bar and address bar the caret is fine, only the message body the caret is still fat and overlapping
Comment 89•20 years ago
|
||
(In reply to comment #88) > in TB version 0.9+ (20041110) looks ok everywhere expect the actually message > body when typing a new email or replying to an email. In the search bar, subject > bar and address bar the caret is fine, only the message body the caret is still > fat and overlapping I think that's basically bug 261054 (that one was fixed on trunk).
Comment 90•20 years ago
|
||
Well. *sigh* There is actually still a small regression. It happens only in the compose text field, not in firefox, not in the thinderbird search or address fields, since they use a different default font. The problem is that with the patch applied only the stuff on the left side of the caret is deleted. For certain letters (above all the "f"s and "/"s) in certain fonts (especially italic fonts and "Gigi") one part of the letter overlaps the caret and therefore isn't deleted when pushing back. That leads to some garbage (eg when typing "ffffffffffffffffffffff" and then deleting it). I cc'ed AARON LEVENTHAL (aaronleventhal@moonset.net) since he is the only one that had a look into nsCaret.cpp for a very long time. Maybe Aaron can come up with a quick fix for this problem. Anyway I cannot suggest to back out the patch again since the regression (which is left) is minor and the garbage doesn't happen under real world usage (who types "fffffffffffffff") and doesn't show up with Firefox at all while the problem that is fixed by this patch shows up everytime. But Scott will have to decide. Maybe we should leave the patch on the trunk and file a separate bug to get some movement with this problem while Scott decides what to do with this on the branch.
Comment 91•20 years ago
|
||
I think the problem mentioned in comment 90, is in fact bug 197129. So that is not a regression from the fix from this bug. I can see the problem mentioned in comment 90 also with Mozilla1.7 Mail from 2004-06-16.
Comment 92•20 years ago
|
||
This bug now shows as RESOLVED and FIXED. When is the fix being released? I've been watching this one now for over 2 years and it annoys me that it's still there.
Comment 93•20 years ago
|
||
How is this bug fixed? A bug is fixed, if the code is in the trunk and I can download a nightly where this bug is not shown any longer. So far I have not seen any such nightly, hence there is no reason to mark this bug as fixed! The latest nightly I can use on windows still shows the bug and the very latest nightly is unusable.
Comment 94•20 years ago
|
||
I can fonfirm that this trunk build contains the fix: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041204 Firefox/1.0+ It is fixed on the branch as well, just test the release candidate of Thunderbird 1.0. BTW, Martijn Wargers seems to be right in comment #91. This comes from heavy caret testing. You stumble over other bugs ;)
Updated•20 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•