[regression] Line break does not work JA page correctly

VERIFIED DUPLICATE of bug 35681

Status

()

P3
major
VERIFIED DUPLICATE of bug 35681
19 years ago
19 years ago

People

(Reporter: teruko, Assigned: troy)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
When you open the Japanese page and change the size of window, the line break
does not change depending on the size of window.

Steps of reproduce
1. Launch Netscape 
2. Go to above URL
3. Select menu View|Character coding->Japanese(EUC-JP)
4. Use mouse to make small the window

Each line should break depending on the size of the window. Lines do not break.
If you move the scroll bar, you can see the whole line.

Tested 2000040509 Win32 M15 build.

I tested this in 2000033112 Beta Win32 build.  Lines breaks depending on the 
size of windows.
(Assignee)

Comment 1

19 years ago
Darn if I know what to do with this bug
Assignee: troy → erik

Comment 2

19 years ago
reassigned to ftang.
qa assigned => teruko
Assignee: erik → ftang
QA Contact: petersen → teruko

Comment 3

19 years ago
Frank, Troy recently made a change in the "text transformer" code, and his
comments suggest that it has something to do with GetNextWord. That's why I
asked IQA to test international line breaking. Now it turns out that it is
broken, but of course we're not sure that it's due to Troy's check-in. I think
it would be a good idea to undo Troy's change in a local tree to see if it has
anything to do with it. Here are Troy's comments from layout.checkins:

Subject: Checkin (layout) - text measurement
From: Troy Chevalier <troy@netscape.com>
Newsgroups: netscape.public.mozilla.layout.checkins

When measuring text in runs the text frame code had been buffering up
the transformed text and when it has accumulated the estimated number of
characters it called the rendering context

This copying needed  for this layer of buffering was slowing us down too
much so I changed the text transformer API for GetNextWord() to have an
additional parameter that indicates whether the buffer should be reset
to the beginning when fetching the next word (default is PR_TRUE and the
buffer is reset to its default position)

This allows the buffering to occur in the text transform objects
internal buffer where we already do a copy of the transformed text
anyway, and eliminates the extra copying the text frame was doing
(Assignee)

Comment 4

19 years ago
It's certainly possible I broke it with my recent changes. Sorry in advance if 
that's the case.

Frank, if you can help narrow down the problem that will be a big help

Thanks
(Assignee)

Comment 5

19 years ago
You guys probably know this, but the text transformer code has a self-test that 
is run the first time the code is executed. It's very helpful in catching 
problems. It caught a couple of problems with my recent changes

Can you expand the self-test code to include more Intl test cases?

Comment 6

19 years ago
troy- please back out your changes. Your change break the CJK line break. Sorry 
that I don't have time to look into this. It will be nice if you let me review 
it before you check and try it on my local tree first next time. 
Assignee: ftang → troy

Updated

19 years ago
Summary: Line break does not work JA page correctly → [regression] Line break does not work JA page correctly

Updated

19 years ago
Blocks: 35012

Comment 7

19 years ago
major loss of function and impacts QA severely
Severity: normal → major
(Assignee)

Comment 8

19 years ago
I have a fix in my tree which I will check in once the tree opens after the
M15 milestone

Comment 9

19 years ago
troy - do you want me to try your fix in my local tree first ? If so, please 
mail me your patch. Thanks.
(Assignee)

Comment 10

19 years ago
No thanks, I was able to test the page myself. It turns out that the problem was 
in the rendering context code. The new function I added that can measure chunks 
of text at a time. It wasn't properly handling the case where it needed to back 
up

The problem wasn't Japanese specific
(Assignee)

Comment 11

19 years ago
Checked in the fix to the GetWidth() function
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 12

19 years ago
I tested this in 2000041306 M15 Win32, 2000041307 M15 Mac and 2000041309 M16 
Win32 build. This still happen in these build. I need to reopen this.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

19 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Comment 13

19 years ago
Here's what I think is going on. There was a problem in the new GetWidth() 
function that measures chunks of text, but I fixed it. I verified using a 
reduced test case of the URL above and it works. It still does.

However, the full test case doesn't work. It still doesn't work even if I turn 
off the code to measure in chunks and we revert to measuring a word at a time

I think the current problem is bug 35681 where the BODY element is getting 
enlarged to accomodate the widest element within it. That in turn causes us to 
think we have enough room and so we don't wrap the text

*** This bug has been marked as a duplicate of 35681 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 14

19 years ago
Verified as dup.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.