[dogfood] [PP] text fields getting improper text

VERIFIED WORKSFORME

Status

()

Core
Layout: Form Controls
P3
critical
VERIFIED WORKSFORME
19 years ago
19 years ago

People

(Reporter: Joe Francis, Assigned: Eric Pollmann)

Tracking

Trunk
PowerPC
Mac System 8.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
Severity: normal → critical
OS: Mac System 8.5 → All
Hardware: Macintosh → All
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M11
(Reporter)

Updated

19 years ago
Summary: text fields getting improper text → [dogfood] text fields getting improper text
(Reporter)

Comment 1

19 years ago
marking as dogfood

Updated

19 years ago
Whiteboard: [PDT+]

Comment 2

19 years ago
Putting on [PDT+] radar.
(Assignee)

Comment 3

19 years ago
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?
(Assignee)

Comment 4

19 years ago
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.
(Reporter)

Comment 5

19 years ago
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.
(Assignee)

Comment 6

19 years ago
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.
(Assignee)

Updated

19 years ago
OS: All → Mac System 8.5
Hardware: All → Macintosh
(Assignee)

Updated

19 years ago
Summary: [dogfood] text fields getting improper text → [dogfood] [PP] text fields getting improper text
(Assignee)

Comment 7

19 years ago
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?
(Reporter)

Comment 8

19 years ago
(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.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 9

19 years ago
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!
(Reporter)

Comment 10

19 years ago
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

19 years ago
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?
(Reporter)

Comment 12

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

Updated

19 years ago
Blocks: 18471

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 13

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

Updated

18 years ago
No longer blocks: 18471
You need to log in before you can comment on or make changes to this bug.