261647 - Most webimages and UI icons are no longer displayed

Status: RESOLVED FIXED

(Core Graveyard :: GFX: OS/2, defect)

Description

[mike.hitchcock]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a4) Gecko/20040925
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a4) Gecko/20040925

Icon toolbar does not display. Using Modern Theme under preferences > appearance
   the "show toolbars as" does not show any buttons to select "pictures and
text","pictures only" or "text only". If load Classic Theme selected, buttons
appear but do not allow selection to stick. Both Browser and Mail are affected.

Reproducible: Always
Steps to Reproduce:
1.Load browser or load mail
2.
3.

Actual Results:  
Toolbar icons do not appear(under Modern theme, no text either)

Expected Results:  
Should should show icons and text for Back, Forward, Reload, Stop, Mozilla and
printer

Seems to be related to bug in theme integration with browser/mail

Comment 1

[mike.hitchcock]

Just noticed that the component selection icons have dissappeared from the
status bar which I assume is related to above bug. Have to select
Navigator/Composer/IRC chat from Window menu

Comment 2

[Peter Weilbacher]

When I saw this effect two days ago I thought it was caused by one of my private
experiments, but I can confirm that now with 
   Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a4) Gecko/20040926
   (official nightly with Build ID 2004092608)
and a new profile. This is an obvious bug, but I did not find any duplicates, so
this is probably OS/2 only.

Hmm, I have gone through the changes between Sept. 19th and Sept. 26th and
backed out several changes in my build, but none gave me back the graphics.

Comment 3

[Peter Weilbacher]

Attachment: Screenshot showing the problem

Strange though, to me it seems that almost all graphics are  no longer
displayed. On webpages I can only see those images that are defined as
background using CSS. On e.g. http://www.mozilla.org/ I only see the mozilla
logo at the top left, the green button, the get-CD graphic and the rotated
Firefox UI screenshot, but not the icons for the other products.

Comment 4

[Peter Weilbacher]

*** Bug 261651 has been marked as a duplicate of this bug. ***

Comment 5

[Peter Weilbacher]

OK, downloaded a few old nightlies and the bug first appears between 2004092208
and 2004092308, so I did a search on bonsai to isolate the problem between these
two dates:
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=2004-09-22+08%3A00%3A00&maxdate=2004-09-23+08%3A00%3A00&cvsroot=%2Fcvsroot

But other than the checkins for bug 261097 nothing rings a bell here, and
backing out that one patch does not help. To be sure I tried to back out the few
other OS/2 relevant changes, but that didn't help either. I'm out of ideas...

Comment 6

[Mike Kaply [:mkaply]]

261097 has to be it.

Did you try building clean from gfx? 

Comment 7

[Peter Weilbacher]

OK, backed out the patch from bug 261097 again and rebuilt clean. Now everything
works. How to proceed further? As a primitive fix we could just bracket the new
code in nsRenderingContextImpl.cpp like this

#ifndef XP_OS2
  nsCOMPtr<nsIRegion> clipRegion;
  GetClipRegion(getter_AddRefs(clipRegion));
  if (clipRegion && !clipRegion->ContainsRect(dr.x, dr.y, dr.width, dr.height))
   return NS_OK;
#endif

I guess this is not what we ultimately want... Or do we just wait until bryner
comes up with a good idea?

Comment 8

[Mike Kaply [:mkaply]]

The problem here appears to be that OS/2 doesn't have an implementation of
ContainsRect.

Comment 9

[Mike Kaply [:mkaply]]

Dainis, please help.

As a result of this change, GpiQueryRegionRects is returning 20BE at this line:

http://lxr.mozilla.org/seamonkey/source/gfx/src/os2/nsRegionOS2.cpp#59

Comment 10

[Dainis Jonitis]

OS/2 has a GpiRectInRegion function. Should be the right thing to implement
ContainsRect. Will try to do this tomorrow.

Comment 11

[Mike Kaply [:mkaply]]

In looking at nsRegionWin.h, for instance, there is a lot of platform region
stuff that we don't have....

Comment 12

[Dainis Jonitis]

We have implementation of all nsIRegion functions, because nsRegionOS2 inherits
all implementation from nsRegionImpl.cpp. ContainsRect seems to be correct, too.

I rather suspect nsRenderingContextOS2::GetClipRegion () which may not correctly
initialize the xp region from OS/2 specific one. If the bug is in
nsRenderingContextImpl.cpp then other Linux ports that use XP-region manager
would be broken, too.

error 20BE = PMERR_INV_REGION_CONTROL

BTW nsRenderingContextOS2::CopyClipRegion () is not implemented.

Comment 13

[Dainis Jonitis]

Attachment: diff -d -u -8

Indeed the problem was in nsRenderingContextOS2::GetClipRegion () which was
calling nsRegionOS2::InitWithHRGN () and later nsRegionOS2::NumOfRects ().

Silly OS/2 wants RGNRECT to be fully initialized with correct values even if we
only want to receive the number of rectangles and not the rectangles itself.

Comment 14

[Mike Kaply [:mkaply]]

Comment on attachment 160728 [details] [diff] [review]
diff -d -u -8

Thanks Dainis - this is it. I'll check it in ASAP.

Should we put this on other branches just in case?

Comment 15

[Mike Kaply [:mkaply]]

Fix checked in.

Awesome jon Dainis.

Comment 16

[Dainis Jonitis]

I think this affects only main trunk 1.8a4+, and before bug 261097 the
GetClipRegion was not used by anything else. 
Although not required, you can safely put it into branches just because this is
right thing (even if it is never called).