Closed Bug 20496 Opened 25 years ago Closed 24 years ago

[REGRESSION] Navigation Toolbar appears bad

Categories

(Core :: Layout, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: shrir, Assigned: pavlov)

References

Details

(Keywords: regression)

Attachments

(3 files)

Using today's commercial build on Linux located at:
ftp://sweetlou/products/client/seamonkey/unix/linux/2.2/x86/1999-12-01-09-M12/ne
tscape-i686-pc-linux-gnu.tar.gz

Try the following:

Install and launch the browser.
Upon  launch, observe that the Navigation toolbar appears dull and wiped off.

Similar to http://bugzilla.mozilla.org/show_bug.cgi?id=17245
Assignee: trudelle → don
Mail, Compose and IM toolbars are fine. reassigning to don
...and yes this is Linux only.
Assignee: don → slamm
Priority: P3 → P2
Summary: Navigation Toolbar appears bad → [DOGFOOD][REGRESSION] Navigation Toolbar appears bad
Target Milestone: M12
Steve, can you reproduce this?  (I don't have a copy of today's Linux build at
home.)
*** Bug 20537 has been marked as a duplicate of this bug. ***
everyone is seeing this on linux, mozilla bits as well.
Attached image screenshot
Are you saying Toolbars cannot be seen at all?
leger: look at my screenshot, attached :-)
i don't see this :(
I see it with a build from last night.  Actually it's a lot more colorful than
Chris' screenshot. :-)  Re-building now to see if the problem still exists ...
problem is still here, and looks different every time I start the app.
I see it too. And the garbage displayed in there changes as I navigate to
different pages.
Whiteboard: [PDT-]
But you're functional...Putting on PDT- radar.
Assignee: slamm → pavlov
something special about pavlov's display works,
solaris/slamm's/akkana's/my displays show this problem.
Pavlov has a special Xserver.?
actually its not working here either.. my xserver is just filling in the undrawn
area with black so it was hard to notice.  if you make the image's
(navbar-bg.gif) width some number bigger than 5 (like 6) (it is currently 1) it
will be fine.
don, your checkin to nsCSSRendering.cpp to fix 16685 caused this one.  We should
always be setting the clip rect/region of something before we draw to a
rendering context.
That comment in that bug was mis-leading.  I took out the extra clipping I was
doing when I was tiling to the screen.. There is a clip present on the
RenderingContext, I just took out the extra clip that used to be there.

The clip I took out is commented out so you can see exaclty where I did this
change,  ~line 2120 in nsCSSRenderingContext.cpp is where I made the change.  I
don't think this caused the problem, or if it did it is revealing another
problem somewere else.
*** Bug 20715 has been marked as a duplicate of this bug. ***
*** Bug 20787 has been marked as a duplicate of this bug. ***
*** Bug 20903 has been marked as a duplicate of this bug. ***
Priority: P2 → P3
Target Milestone: M12 → M13
setting p3 for m13 to get off m12 radar. Slamm, why did you assign this to Pav?
It seems app-specific, since other toolbars work fine.
don,  backing out your change to that setcliprect fixes the problem.  i don't
know whats up...
Target Milestone: M13 → M12
trudelle: the problem is the background image of the nav bar, which is only used
there, that's why it's only showing up on one toolbar.

m13?  Take the damned background out, back to m12 for workaround.
PDT-, huh?
Talked with pavlov, he's gonna get with dcone about this tomorrow
and try and get a fix or a workaround.
Target Milestone: M12 → M13
McAfee: I don't care how easy this is to fix, it is not required for M12. Please
do not retarget my team's bugs.
Pavlov, this is not something that you should be spending time on, especially
in the last 24 hours before a deadline. If someone who doesn't have PDT+ bugs
wants to remove it, fine.
Moving to M13, for the third time, and I expect it to stay there.
This is an ugly regression. Why is this pushed out to M13? Sure it does not
change the function of the browser, but it looks terrible. Even if there are
other functional problems, this should receive priority since it forms the first
impression of the browser.
I have a workaround fix ready to go, we pull the background image
and change the toolbar color.  10 min. of work.  dcone is testing
the real fix, I suggest we take one of these fixes ASAP.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
fixed.
Looks great!
*** Bug 21663 has been marked as a duplicate of this bug. ***
*** Bug 21790 has been marked as a duplicate of this bug. ***
*** Bug 20526 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
fixed long ago...., marking VERIFIED
Reopening bug. Seeing this on today's commercial build on Linux for M14 
(2000012609).
Status: VERIFIED → REOPENED
Target Milestone: M13 → M14
Clearing FIXED resolution due to reopen.
Resolution: FIXED → ---
*** Bug 25126 has been marked as a duplicate of this bug. ***
Blocks: 25824
*** Bug 25768 has been marked as a duplicate of this bug. ***
Status: REOPENED → ASSIGNED
Keywords: beta1
Whiteboard: [PDT-]
No longer blocks: 25824
*** Bug 26284 has been marked as a duplicate of this bug. ***
*** Bug 26284 has been marked as a duplicate of this bug. ***
PDT+
Whiteboard: [PDT+]
So is this supposed to be PDT+ dogfood or beta1? There is no comment. This is 
not preventing anyone from using the product, or even hindering their use of the 
product, so I'm hoping that it is beta1.
beta1 i hope.
I hope that this bug gets fixed as soon as possible, because in my mind, this is
certainly is hampering people's use of mozilla. I mean, come on! Say for
example, someone who has been waiting out on mozilla hears that it is finally
alpha.  "Great," they think," maybe it's starting to become the browser I've
been hearing about!" So they download it, un-tar it, load it, and what's the
first thing they see? Garbage strewn up and down the toolbar, and as a result, a
browser that looks like a super-buggy piece of ****.  Yes, this is certainly
"hindering their use of the product."
Yes, PDT+ for beta1.
*** Bug 26414 has been marked as a duplicate of this bug. ***
Putting dogfood in the keyword field.
Keywords: dogfood
fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Today I downloaded debian's m13 build, from jan 26 -- it exhibited the
corruption, when debian's m12 build from mid december does NOT show the
corruption. I do hope that it is fixed; it was hard to convince friends that
mozilla was a good web browser when it looked so blasted ugly... :)

Thanks :)
Blocks: 25824
looks fixed in the 2000020708 Linux RH6 builds. lets hope it stays that way this time. Marking VERIFIED.
Status: RESOLVED → VERIFIED
*** Bug 27448 has been marked as a duplicate of this bug. ***
No longer blocks: 25824
*** Bug 27370 has been marked as a duplicate of this bug. ***
Reopening. Seing this on today's linux commercial  build (2000042409).
Status: VERIFIED → REOPENED
Keywords: beta1, dogfood
Resolution: FIXED → ---
Summary: [DOGFOOD][REGRESSION] Navigation Toolbar appears bad → [REGRESSION] Navigation Toolbar appears bad
Whiteboard: [PDT+]
Target Milestone: M14 → M16
I think this is because I put my changes in for Tileing to happen in the 
RenderingContext.. and in the nsRenderingContextImpl::DrawTile method.. the 
#ifdef for XP_UNIX is not there.  If you add this.. I think this problem will go 
away.  Just a temporary solution until you get your other tiling code working.
Keywords: regression
*** Bug 37048 has been marked as a duplicate of this bug. ***
when preferences is now loaded and i select fonts, i also observe that the
heading there actually "animates" the garble while the content of boxes are
loaded in. Indicates that a lot of probably unwanted refreshes of the titlebar
in prefs are going on, for some reason.
*** Bug 37236 has been marked as a duplicate of this bug. ***
dcone -
If this is "because I put my changes in for Tileing to happen in the 
RenderingContext.." then you broke unix. you should either back out your change 
or fix unix.
reassigning to dcone.  don, could you please check in the fix for this?
Assignee: pavlov → dcone
Status: REOPENED → NEW
Component: XP Toolkit/Widgets → Layout
The fix was a platform specific fix in cross platform code.  I thought Pavlov 
had a fix for the GTK platform.. so my comment was mearly a heads up that if you 
had your fast tiler working.. this bandage (#ifdef XP_UNIX ) did not need to get 
in.  If you were going to be a few days longer.. then put the #ifdef back in 
until it worked.  I will fix it.. but its just a bandage..and will have to be 
taken out when Pav has his stuff working.
Status: NEW → ASSIGNED
above patch seems to fix the problem (band-aid wise). there a re a few glitches
at the right end of the tolbar, but windows seems to have them as well so they
must either be generic tiler issuesor XUL/CSS issues).
I think that's just some lame XUL - nice patch puetzk!
Putting on nsbeta2 nomination.
Whiteboard: nsbeta2
Putting on nsbeta+ radar.  but this is so bad, PDT can we get a dogfood 
consideration?
Keywords: dogfood, nsbeta2
Whiteboard: nsbeta2
this will be fixed today... I will put the bandage back in.. I have been doing 
other things to nsRenderingContextImpl that prevented the  temporary fix.. but 
it is now ready to go in as soon as the tree opens...
reassigning
Assignee: dcone → pavlov
Status: ASSIGNED → NEW
checked in patch.
Status: NEW → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
Thanks Stuart.. beat my checkin by a few minutes.. 
Let me know when your tiling stuff is finished and I will take out this 
patch....
*** Bug 37533 has been marked as a duplicate of this bug. ***
VERIFIED Fixed with the 2000050109 builds
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: