34731 - [regression] Line break does not work JA page correctly

Status: VERIFIED DUPLICATE of bug 35681

(Core :: Layout, defect, P3)

Description

[Teruko Kobayashi]

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.

Comment 1

[troy]

Darn if I know what to do with this bug

Comment 2

[bobj]

reassigned to ftang.
qa assigned => teruko

Comment 3

[Erik van der Poel]

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 <[e-mail]>
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

Comment 4

[troy]

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

Comment 5

[troy]

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

[Frank Tang]

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. 

Comment 7

[bobj]

major loss of function and impacts QA severely

Comment 8

[troy]

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

Comment 9

[Frank Tang]

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

Comment 10

[troy]

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

Comment 11

[troy]

Checked in the fix to the GetWidth() function

Comment 12

[Teruko Kobayashi]

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.

Comment 13

[troy]

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 ***

Comment 14

[Teruko Kobayashi]

Verified as dup.