MantisBT - NetSurf |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0002189 | NetSurf | [All Projects] General | public | 2014-09-02 01:12 | 2015-03-10 23:44 |
|
| Reporter | Harriet Bazley | |
|---|
| Assigned To | Michael Drake | |
|---|
| Priority | normal | Severity | minor | Reproducibility | always |
|---|
| Status | closed | Resolution | fixed | |
|---|
| Platform | ARM | OS | RISC OS | OS Version | 5.19 |
|---|
| Product Version | 3.2 | |
|---|
| Target Version | 3.3 | Fixed in Version | 3.3 | |
|---|
| Fixed in CI build # | 2126 |
|---|
| Reported in CI build # | 2021 |
|---|
| URL of problem page | |
|---|
|
| Summary | 0002189: Redraw issues at ends of lines in text boxes |
|---|
| Description | When editing text in a text box on a Web form, Netsurf can fail to redraw the ends of lines correctly if the edit causes text to rewrap. The 'ghost' of the word that was previously at the start of the new line can be left visible in place of the replacement text.
Unfortunately this doesn't seem to be universally applicable (I've failed to get the issue to show up on the text entry boxes on this page, for example, even after switching to a proportional font), which makes it harder to demonstrate. This redraw problem often happens to me when using the GMail web interface, for example, and when using the 'private messaging' system on Fanfiction.net. |
|---|
| Steps To Reproduce | Open the GMail 'Compose Mail' window using the Basic HTML interface. Paste in the text "Yes, there is in fact a plot for this one under all the angst-- not much of a plot idea, but Chapter 1 was never more than just an isolated vignette!" (Image 1)
Place the cursor at the start of the second line, before the word "just", and delete the space between this word and the preceding word, thus creating a new word "justnever" and forcing Netsurf to rewrap it onto the line below. The 'ghost' of the old word "never" is still visible at the end of the first line, and the words "just a" are visible in their old position at the start of the second line as well as in their new position further along the line. (Image2)
Forcing a redraw by dragging another window over the left-hand side of the text box reveals the true state of affairs on the second line, though the first line has not yet been redrawn here (Image3).
Second example: usaing the same initial text, place the cursor at the end of the first line after the word "never", and insert the words "more than". There is only room for the letter "m", so after this is typed all the next text has to rewrap onto the line below. However, the first two letters on the new line never get redrawn, and the "m" is still visible in its initial position at the end of the first line (Image4) |
|---|
| Tags | No tags attached. |
|---|
| Relationships | |
| Attached Files |  redraw.zip (22,408) 2014-09-02 01:12
https://bugs.netsurf-browser.org/mantis/file_download.php?file_id=185&type=bug |
|---|
|
Notes |
|
|
|
|
What format are these images? |
|
|
|
|
|
Does this only happen when editing the first line of the textarea, and where it wraps to the second line? |
|
|
|
|
The files are RISC OS sprite files - standard snapshots from Paint taken in a 16M colour mode. I can upload versions processed into JPEG format if needed.
I usually see this at the bottom of a long textarea entry when I'm editing text just typed, so it definitely applies to lines beyond the first. I can confirm that I still see the behaviour as described in version 2117. |
|
|
|
|
|
PNG is best, but don't worry about upoading them, I've reproduced the issue for myself. |
|
|
|
|
Please try build 2126. Hopefully no new redraw bugs were introduced.
|
|
|
|
|
|
Confirmed fixed in 3.3 release |
|