17820 - [dogfood] [PP] text fields getting improper text

Status: VERIFIED WORKSFORME

(Core :: Layout: Form Controls, defect, P3)

Description

[Joe Francis]

In apprunner:
go to any buzilla bug report.  Then alter the URL to a different bug# and hit
enter.  When new bug loads, note that the summary has the wrong text (do a view
source to see the correct text).  You may have to go through several bugs before
this happens.  Eventually, you will start seeing the same summary for every bug.

Comment 1

[Joe Francis]

marking as dogfood

Comment 2

[leger]

Putting on [PDT+] radar.

Comment 3

[Eric Pollmann]

I'm not able to reproduce this bug on Linux or Solaris.  Still waiting on my NT
machine to test the build there.  Can you please include specific instructions
on how to reproduce this?

Comment 4

[Eric Pollmann]

For example:
Which platform, bug numbers?
Viewer or apprunner?
Are you scrolling down to bring the summary field into view or is the window
expanded large enough to see it?
Is the rest of the window repainting completely?  (Are other controls also not
updated?)
In viewer and apprunner, do the content model and frame model both have the
correct text?

Thanks.

Comment 5

[Joe Francis]

I see this one mac.  Perhaps it is mac only?
Any bug number.  Apprunner.  No scrolling needed.  Other text controls are also
keeping text from past bugs.  Don't know about the content/frame model.  View
source had the correct text, and layout displayed the wrong text.

I'll try to reproduce this with a recent build and update you on the results.

Comment 6

[Eric Pollmann]

I can not reproduce this bug, can someone with a Mac take a look?

Just tested this with a CVS pull from this afternoon on NT and Linux.  I went to
http://bugzilla.mozilla.org.  Typed 1234 into the bug number box.  I then
clicked in the URL bar after the 4, and replaced the 4 with a 5 then pressed
enter.  Repeated this procedure, incrementing the number by 1 each time for over
a dozen times and each time all text fields were updated correctly.

Could this be a painting problem on Mac?

One way to check would be to run Viewer (not Apprunner) and use the debug menu
to dump the content model and frame model.  If the text is right in both of
those places this might be a painting problem.  If it is wrong, than there is
something messed up with the Gfx text widgets, parser, or frames.

Comment 7

[Eric Pollmann]

Here are three more things to try that may narrow down the problem:

1) Force a repaint.  Drag another window in front of the text fields in the
mozilla window.  When the window is removed, is the text still wrong?

2) Force a reflow.  Resize the window to make it narrower.  When the page
finishes displaying, are the text fields still wrong?

3) Force a reload.  Click on the reload button in apprunner.  When the page
finishes displaying, are the text fields still wrong?

Comment 8

[Joe Francis]

(still haven't tried this on recent build, will do RealSoonNow) I remember trying
forcing a redraw and forcing a reload, and they didn't help.  I don't think i
tried resizing.

Comment 9

[Eric Pollmann]

Pierre was just kind enough to try this for me with the most recent Macintosh
binary build available from mozilla.org.  We are not seeing this problem in that
build.  I'm hoping that you will see the same thing, and marking this bug
WORKSFORME.  Thanks!

Comment 10

[Joe Francis]

dagnammit.  I can't reproduce it now either.  I know I didn't imagine it because
I reproduced it when I originally filed the report.  The only thing I may have
done before (that I didn't mention) is to actually click on the text fields (I
was exploring some wierdness with the recent "defer editor construction" work).
I just tried all this for 5 minutes through about 30+ bugzilla bugs and could not
reproduce the problem.

Comment 11

[buster]

could it be session history related?  joe and eric, did you try reproducing by
going foward and backward between page loads where the pages are all bug
reports?  When Joe first told me about this bug, I thought he said something
about that.  Maybe not...Joe?

Comment 12

[Joe Francis]

I should have mentioned that.  I tried using forward/back in my recent test as
well.

Comment 13

[cpratt]

if the report can't verify it, i'll verify it as wfm.