Closed Bug 116593 Opened 24 years ago Closed 23 years ago

Viewer Demo 14 doesn't behave as expected. Screen fails to update, sorting alternate style doesn't sort correct

Categories

(Core :: XML, defect, P1)

Product:
Core
Component:
XML
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: kisai_z, Assigned: waterson)

References

(
URL
)

Details

(Keywords: helpwanted, regression, Whiteboard: [ADT2])

When running the XML sorting demo, part of the screen isn't updated when clicking the different buttons to sort by. When switching to the alternate style with the pictures, the pictures aren't being re-arranged, instead only three of the pictures referenced are even being used.
The scrolling is also strange, scroll one and the other texts scroll instead and not properly. I filed a bug against this demo a while ago for another scrolling related problem but it was marked future. http://bugzilla.mozilla.org/show_bug.cgi?id=43340 It's probable that people still do not have the time to fix this, but perhaps it would be an idea to temporarily remove this demo from the menu as it behaves so badly.
Confirming issue when pressing "Author" button. Tested with the Jan 2nd build (2002-01-02-12).
Status: UNCONFIRMED → NEW
Ever confirmed: true
I don't think anything I have done could be the cause of this. This looks like painting issue because when I cover the window with another window and then show it again everything is as it should. Cc: dbaron who might have an idea where to look.
*** Bug 111788 has been marked as a duplicate of this bug. ***
I don't see the problem in a Linux trunk build from a week or so ago.
I don't have linux machine to test right now, but I see this on Win2k at least. And this is a regression I believe. I can't remember who did the paint reduction optimization, but this might have something to do with it. Cc: waterson and hyatt. I have also seen warnings in the debug console for a few months now in certain XML pages. For example, when you toggle the style in viewer demo 14 you get stuff like: frame: Block(Book)(1) (04706B34) style: 04704B28 {} Wrong parent style context: style: 047047F0 {} should be using: style: 04702DA8 {} frame: Block(Book)(2) (047062D4) style: 04704B28 {} Wrong parent style context: style: 047047F0 {} should be using: style: 04702DA8 {} ... When I open mozilla/content/xml/tests/xmlbase/xmlbase.xml I get these kinds of messages: Block(p)(5)@0471A63C: Init: bad caller: width WAS 1073741749(0x3fffffb5) Block(sect1)(7)@0471A858: Init: bad caller: width WAS 1073741524(0x3ffffed4) Block(title)(1)@0471A974: Init: bad caller: width WAS 1073741524(0x3ffffed4) Block(sect1)(7)@0471A858: Init: bad caller: width WAS 1073741524(0x3ffffed4) Block(p)(5)@0471AC48: Init: bad caller: width WAS 1073741449(0x3ffffe89) Block(sect1)(7)@0471A858: Init: bad caller: width WAS 1073741524(0x3ffffed4) Block(sect2)(7)@0471AE64: Init: bad caller: width WAS 1073741224(0x3ffffda8) Block(title)(1)@0471AF80: Init: bad caller: width WAS 1073741224(0x3ffffda8) Block(sect2)(7)@0471AE64: Init: bad caller: width WAS 1073741224(0x3ffffda8) Block(p)(5)@04733D20: Init: bad caller: width WAS 1073741149(0x3ffffd5d) Block(p)(5)@0471A63C: Init: bad caller: width WAS 1073741749(0x3fffffb5) ... ###!!! ASSERTION: bad math, newAvailWidth is infinite: 'NS_UNCONSTRAINEDSIZE != newAvailWidth', file c:\builds\mozilla\layout\html\base\src\nsBlockFrame.cpp, li ne 1861 ###!!! ASSERTION: bad math, newAvailWidth is infinite: 'NS_UNCONSTRAINEDSIZE != newAvailWidth', file c:\builds\mozilla\layout\html\base\src\nsBlockFrame.cpp, li ne 1861 Block(sect1)(7)@0471A858: Init: bad caller: width WAS 1073741524(0x3ffffed4) ...
Keywords: regression
*** Bug 118809 has been marked as a duplicate of this bug. ***
*** Bug 121374 has been marked as a duplicate of this bug. ***
Chris P., could you please find out when this regression happened?
Keywords: qawanted
Priority: -- → P1
Target Milestone: --- → mozilla1.0
Heikki, I went back to the Nov 19th build (OS X build) and can reproduce the following: When clicking on either title, Author, ISBN buttons, the first "list" item title is only partially displayed. I need to try on Windows to see if I can get a even older build to track it down.
On Windows, this problem began on the 11/24/2001 trunk build (2001-11-24-08). The previous trunk build (11/23) worked fine. Tested under Windows ME.
With the OS X build, I can't find a older trunk build than the Nov 19th so I don't have the ability to track it down any further.
*** Bug 130275 has been marked as a duplicate of this bug. ***
Hmm... I checked Bonsai for checkins from 11/23/2001 00:00:01 to 11/24/2001 23:59:59, and there didn't seem to be much that could have caused this: dbaron: bug 109788 separate text frame frame construction from other frame construction (this was partly backed out during this time, and this happened at 11/24 15:28 so way after the build where there were problems). roc+moz: bug 73382 cleanup view manager (backed out during this time, did this break something?) Of course a lot has happened since then so the current problem might be caused by something else. Bonsai link: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=11%2F23%2F2001+00%3A00%3A01&maxdate=11%2F24%2F2001+23%3A59%3A59&cvsroot=%2Fcvsroot
Keywords: qawanted
ADT3 per ADT triage.
Whiteboard: [ADT3]
*** Bug 131752 has been marked as a duplicate of this bug. ***
*** Bug 131772 has been marked as a duplicate of this bug. ***
*** Bug 131847 has been marked as a duplicate of this bug. ***
The roll-back of the patch of bug 73382 on 11/23/2001 21:36-21:37 clearly made this bug appear, but I think it made it reappear. After a long binary search of re-pulling and re-building I have a build from 21:35 on that day that displays correctly, and one from 21:39 on that day that does not. Unless the rollback was not done correctly, I think that perhaps the patch caused the bug to disappear by repainting too often, which showed up as a 5% performance hit, which was then rolled back, so the bug would have reappeared. I may check to see that the bug was there before, but one should assume a perfect rollback would have been trivial to achieve. It is easy to see that it is a problem with a missing or badly-clipped repaint if you minimize and then redisplay because tthis fixes the problem. Unless someone thinks that the extra paints caused by the patch were appropriate (I think they were probably just misleading), then this had little to do with the real bug. What is NOT broken at all in any build from Nov 23 to Nov 25 that I tried is the problems currently seen in the scroll bars, which would seem to be a seperate regression.
I verified that the bug (the repaint, not the scroll-bar) is there on November 20, 2001 -- before the patch whose rollback caused it to reappear -- and in milestone 0.9.6. It does not seem to be there in milestone 0.9.5, or 0.9.4.
*** Bug 135271 has been marked as a duplicate of this bug. ***
*** Bug 136033 has been marked as a duplicate of this bug. ***
Blocks: 137224
I think mozilla.org should consider this as 1.0 stopper. This is perhaps the oldest and most widely used XML example that people use to demonstrate Mozilla. This also needs attention. We still haven't pinpointed when this happened exactly, and we have no idea what caused it/how to fix it. Layout is also not my strongest area so help is needed...
Keywords: helpwanted, mozilla1.0
Depends on: 129115
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
Target Milestone: mozilla1.0 → mozilla1.0.1
No No No, PLEASE let's not nsbeta1- this.
need for evangelism road shows. taking the minus off for reconsideration.
Keywords: nsbeta1- → nsbeta1
taking...
Assignee: heikki → waterson
*** Bug 140540 has been marked as a duplicate of this bug. ***
adding back nsbeta+ and raising the impact.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [ADT3] → [ADT2]
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0.1 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 143545 has been marked as a duplicate of this bug. ***
Bug is still valid in RC2 on W2k. Simply "waving" another window over the flawed demo causes a correct redraw; same for switching to another tab/window that is displayed over the faulty demo window. Yet, on a dual head display system, switching between faulty Mozilla window and another app, which is on the secondary display, does NOT fix it. It's becoming more challenging to "capture" a screen shot of the bug. Activating any screen grabber causes an instant redraw of the screen in faulty Mozilla window. It looks like only a web camera can do it now. :-)
Here's a screen shot from just a few days ago : http://bugzilla.mozilla.org/attachment.cgi?id=83097&action=view
This bug went out with Mozilla 1.0 :-( but appears fixed on trunks (I'm not certain of this, though).
This should be fixed with the checkin for bug 129115 on the branch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Keywords: fixed1.0.1
Resolution: --- → FIXED
I wanted to see if this very old bug was fixed: http://bugzilla.mozilla.org/show_bug.cgi?id=43340 Turns out that Viewer Demo 14 won't even load at all now.
Verified fixed on Windows ME (2002-07-16-08) and OSX (2002-07-16-05) branch builds.
Keywords: verified1.0.1
Verified on trunk builds (2002-07-10-08 OS X ) and (2002-07-16-08 Win ME).
Status: RESOLVED → VERIFIED
Note, Tested on the 20020714 build and it didn't load, tested on th 2002071813 build and it works again.
You need to log in before you can comment on or make changes to this bug.