Closed Bug 137982 Opened 22 years ago Closed 22 years ago

Page elements are sometimes misdrawn as grey boxes or in wrong position

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.2

People

(Reporter: bugmail, Assigned: dcone)

References

(
URL
)

Details

(Keywords: testcase, top100, topembed+, Whiteboard: Self-explanatory testcase at URL above)

Attachments

(4 files)

Screen shot showing Navigator display corruption.
105.90 KB, image/png
Details
what Grap.app saw
116.94 KB, image/png
Details
removed a check in scroll for visibility.
585 bytes, patch
Details | Diff | Splinter Review
Alternative nsWindow.cpp patch
1.71 KB, patch
dcone
: review+
sfraser_bugs
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1)
Gecko/20020416
BuildID:    2002041618

Page display corrupts if the Bugzilla Query Page has to reload to do its'
"adding form fields" operation.

Reproducible: Always
Steps to Reproduce:
1. Access the Bugzilla Query Page
2. Type some text into the Summary field
3. Submit the query

Actual Results:  Bugzilla does its' "adding form fields" operation (I still have
no idea what or why Bugzilla does that, but that's another story) and redisplays
the Query Page, but display is corrupt.

Expected Results:  Page display should not have been corrupt.

A screenshot will shortly be attached hereon.
Are you using XBL form controls or regular form controls?
I'm using regular form controls.
I have this problem too. To reproduce, load

http://bugzilla.mozilla.org/query.cgi

scroll to the bottom of the page and type "form control" in the Summary field,
then press enter.

I have had this problem for a while; it is not new in this build.
Confirmed on 2002041710 on Mac OS 9.2.2.  Changing OS to All as not limited to
Mac OS X.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
Keywords: mozilla1.0
Reassigning to John
Assignee: attinasi → jkeiser
Confirming issue on OSX (2002-26-05) branch. Setting Priority to P2.
Priority: -- → P2
I mean 2002-04-26-05 OS X branch.
I just tried this in the latest OS X build (2002-05-03-09) and can't reproduce.
Anyone see this issue with the same build ?
It doesn't reproduce because my steps no longer cause the Query page to reload.

Does anyone know what condition causes the Query page to reload with that
"adding query fields" nonsense?
*** Bug 141665 has been marked as a duplicate of this bug. ***
*** Bug 148050 has been marked as a duplicate of this bug. ***
*** Bug 151569 has been marked as a duplicate of this bug. ***
I suspect this may be related to my bug 152064.
Note that this still occurs using FizzillaCFM/2002062203.
*** Bug 152064 has been marked as a duplicate of this bug. ***
Changing this bug to better reflect the problem, seeing that Bug 152064 has been
duplicated to this.

I also made a better testcase on that bug than on this one. Adding its' URL to
this bug. To use the testcase:

1. Access the testcase URL
2. Click the "Link with hash"

Actual Results:  A grey box was drawn in the upper-left position of the content
pane, in the same position the real IFRAME would be drawn if the URL was
accessed without the hash portion (try the "Hashless link" for comparison).

Expected Results:  The grey box should not have been drawn at all, and the text
underneath should have been completely visible.

Scrolling the page doesn't correct display, but resizing the window does.
URL: http://bugzilla.mozilla.org/query.cgi → http://greg.tcp.com/mozilla/Test%20Ca...
Summary: Navigator display corrupts after form submission/redisplay → Page elements are sometimes misdrawn as grey boxes
Summary: Page elements are sometimes misdrawn as grey boxes → Page elements are sometimes misdrawn as grey boxes or in wrong position
*** Bug 156260 has been marked as a duplicate of this bug. ***
Currently the query page displays with gray boxes when you press Back while
viewing a query result.
Possibly the same problem as in bug 157001.
Depends on: 157001
Keywords: nsbeta1
*** Bug 157042 has been marked as a duplicate of this bug. ***
*** Bug 158955 has been marked as a duplicate of this bug. ***
FWIW, this bug appeared between 0.9.9 (2002031005) and 1.0RC1 (2002041712).
No longer depends on: 157001
Per comment 5, setting OS to 9.x. All would have to include Linux.
OS: All → Mac System 9.x
Keywords: testcase
John, 

Any status update on resolving this bug ?
*** Bug 160844 has been marked as a duplicate of this bug. ***
taking
Assignee: jkeiser → dcone
*** Bug 161916 has been marked as a duplicate of this bug. ***
*** Bug 162045 has been marked as a duplicate of this bug. ***
nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Keywords: mozilla1.0
Whiteboard: Self-explanatory testcase at URL above
*** Bug 163311 has been marked as a duplicate of this bug. ***
*** Bug 148572 has been marked as a duplicate of this bug. ***
Attached image what Grap.app saw — 
Copying over screenshot from bug 148572.  This is a funny one, I saw the grey
boxes, but Grab.app saw this instead.  I have no idea what to make of that.
*** Bug 164267 has been marked as a duplicate of this bug. ***
I posted one of the dups for this bug, but it's still present under 1.1 Final on
OS X (10.1.5). I notice this happens most often (for me) on Bulletin Board
systems that use Open Topic. For example, over at Ars Technica this occurs
*every* time I refresh a thread page I have posted to. They are now using Open
Topic 2.3.0.
*** Bug 165475 has been marked as a duplicate of this bug. ***
*** Bug 166116 has been marked as a duplicate of this bug. ***
Invisible elements need to be scrolled also, seems the IFrames are set
invisible when they are scrolled offscreen initially.  This fix lets these
frames move themselves off the screen and sync up.  This check is not on any
other platform.  Mac is unique in that we have to maintain the offset of these
windows ourselves so breakin from the scroll code was not a good thing.
Comment on attachment 99112 [details] [diff] [review]
removed a check in scroll for visibility.

r=rods
Comment on attachment 99112 [details] [diff] [review]
removed a check in scroll for visibility.

You should ensure that this change doesn't regress page load performance, or
scrolling performance, by causing unucessary invalidates, especially when
browsing with multiple tabs.
Also, how does this relate to the work that roc+moz@cs.cmu.edu has been doing?
I think I have duplicates of this bug filed against me. As far as I know these
problems are all Mac-only.
if I leave that check in.. IFrames and some other widgets are drawn incorrectly
using the back button or an anchor tag on a page going to another page. 
Performance is really secondary to the page looking right in this case.  If the
performance does degrade on page loads that are pre-scrolled.. the performance
will have to be fixed some other way.. because the offsets need to be set for
these windows when things are scrolled.. right?  
also
1.)  The routine I put the fix in "::scroll" is a very small part of this
performance fix.
2.)  The routine I put the fix in is only hit for a page load if the page is
scrolled before the load (like a page back or page forward).  So for normal page
loads this routine is not hit and can not degrade the load performance.
3.)  When it is hit for a page load.. it really needs to do the things in that
routine so it can sync up the offsets.
4.)  Just to make sure I did page loads that were not pre-scrolled and this
routine was not called.
This patch seems more sensible to me: only do the invalidation stuff in Scroll
if the widget is visible, but always move the child widgets, and recalc window
regions.
Keywords: review
*** Bug 148075 has been marked as a duplicate of this bug. ***
Comment on attachment 99133 [details] [diff] [review]
Alternative nsWindow.cpp patch

r=dcone.  This works with my test cases.
Attachment #99133 - Flags: review+
can you sr this simon.. or is that against super review policy???
Comment on attachment 99133 [details] [diff] [review]
Alternative nsWindow.cpp patch

sr=sfraser. A fine patch indeed!
Attachment #99133 - Flags: superreview+
Keywords: review → approval
Oh Frabjous day!  Nominating for MOZILLA_1_0_BRANCH
Keywords: adt1.0.1, mozilla1.0.2
Is this checked into the trunk?
Added top100, topembed+ keywords to this bug from bug 148075
Keywords: top100, topembed+
This landed on trunk today but wasn't marked FIXED.  Doing so now so that it'll
be evaluated for MOZILLA_1_0_BRANCH
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Nominating for the 1.0 branch, as this would be a good thing to get resolved for
a mjor embeddor (e.g. topembed+, top100).
Keywords: adt1.0.1 → edt1.0.2
Target Milestone: --- → mozilla1.0.2
The testcase URL does now appear to work using FizzillaCFM/2002091708. Great
job, dcone and sfraser!
Comment on attachment 99133 [details] [diff] [review]
Alternative nsWindow.cpp patch

a=asa (on behalf of drivers) for checkin to the 1.0 branch.
Attachment #99133 - Flags: approval+
Awesome, this bug is finally dead ! Verified on OS X 2002-09-17-08 Trunk and OS
9.1 2002-09-17-08 trunk builds.
Status: RESOLVED → VERIFIED
edt1.0.2+ (per verbal from saari) approval for landing on the 1.0 branch,
pending Drivers' approval. Pls land time asap, then replace "mozilla1.0.2+" with
"fixed1.0.2". thanks!
Keywords: edt1.0.2 → edt1.0.2+
Marking as "Mozilla1.0.2+" per comment Comment #55 From Asa Dotzler.
Keywords: mozilla1.0.2 → mozilla1.0.2+
The check for visiblity is not in the code for the branch.. so this problem does
not exist there.  I am not sure how to mark this.. since it will not be fixed on
the branch since the problem does not exist there.
This fix is most certainly needed on the branch as I see the incorrectly drawn
grey boxes constantly in Netscape 7.0
I just repulled that file.. and I don't get those changes.. I will repull the
entire branch.. see if I get it.  Very very strange indeed.
Anybody have any idea what might have introduced this bug? (See comment 23.)
Re-pull updated to correct version, something is wrong with the cvs update..
need to investigate that. I checked the fix into the branch.
Keywords: mozilla1.0.2+ → fixed1.0.2
Greg: yes, I believe it was my optimization to not redraw invisible widgets.
petersen: can you pls verify this as fixed on the 1.0 branch, then replace
"fixed1.0.2" with "verified1.0.2". thanks!
Verified on branch (2002-09-18-05) under OS X 10.2.
Keywords: fixed1.0.2 → verified1.0.2
*** Bug 140509 has been marked as a duplicate of this bug. ***
*** Bug 134894 has been marked as a duplicate of this bug. ***
*** Bug 138709 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: