Mozilla for BeOS doesn't display images on many sites.



Core Graveyard
16 years ago
9 years ago


(Reporter: John Slevin, Assigned: Paul)




Firefox Tracking Flags

(Not tracked)



(2 attachments, 5 obsolete attachments)



16 years ago
Mozilla for BeOS doesn't display images on many web sites.  I tested several
builds in BeOS and they all exibit the same problem.  Mozilla 1.0 in Linux
doesn't have this problem.  I'll list a few sites that have this problem.
Zaranthos: ah, fill in the fields, and when you tab to the button it vanishes


16 years ago
Priority: -- → P5
Target Milestone: --- → mozilla1.1beta
tried to clean the cache or so? Reproducing a BeOS Bug is a bit complicate...

Comment 2

16 years ago
Tabbing to a button may make the image appear/disappear.  Scrolling the screen
up/down make make an image appear/disappear.  Moving the mouse over an image
make make it appear/disappear as will reloading a page sometimes.

Clearing the cache doesn't help.  The problem can be reproduced very easily on
many sites and happens the first time or everytime you visit the problem sites.
please don't set the target milestone or the priority unless you are the
assigned devloper - thanks

Keywords: qawanted
Priority: P5 → --
Target Milestone: mozilla1.1beta → ---

Comment 4

16 years ago
Over to ImageLib.
Assignee: Matti → pavlov
Component: Browser-General → ImageLib
QA Contact: asa → tpreston

Comment 5

16 years ago
problem is not that it don't show them at all, rather than those images
disappears. Or appears on some user actions, and then disappears again.
Installed BeOS here and I can reproduce the problem with a recent Mozilla
Ever confirmed: true
hm.. I have an "image ghost" here.. some images are displayed as being missing,
but loading them manually let them show up. The you go back to the page and they
are there. Shitf+reload -> image gone again... same bug?

Comment 8

16 years ago
Yes, Kai, that is this bug

Comment 9

16 years ago
It seems there are different reasons for those sites.
With last BeOS patches and maybe changes in above mozilla code, site *
Other mentioned here still have problems

Comment 10

16 years ago
I have a feeling this is a network issues.  This is why Sergei does not see the problem, 
since he is running BONE, which has a better network configuration.  BeOS net_server is
crappy, to say the least.  
My hunch is that this is within NSPR as well (maybe a blocking issue), but have not
been able to verify this.  There is currently another bug, which I think has a patch that
I have not had a chance to test, for getting PRLog to a file working under BeOS again.
Once I have done that, I need to add some logging to the BeOS networking code, and try
to figure out what is going on in there with these images.

I can almost always see this on, in the icons for the articles.
It seems as if mozilla gives up trying to load the image too quickly.

Comment 11

16 years ago
I see all those issues under BONE too.
Just one site from examples works bit better for me now
and i really doubt that it is (only) network-related. 
I think that this problem needs also ivestigation of code for those pages.

Comment 12

16 years ago is the latest victim of the image not displaying bug.

Comment 13

16 years ago
Reminder - should study code from 

Comment 14

16 years ago
Bug #1: code for ContainsRect in nsRegionBeOS is wrong.
Intersects != Contains !!!!

Comment 15

16 years ago
from the nsIRegion.h file:/**  * does the region intersect the rectangle?  *  * @param      rect to check for containment  * @return     true if the region intersects the rect  *  **/  virtual PRBool ContainsRect(PRInt32 aX, PRInt32 aY, PRInt32 aWidth, PRInt32 aHeight) = 0;So, do we believe the comment or the method name?  If the comment, then our implementationis correct.  If we take the method literally, then it must be fully contained within the rect.

Comment 16

16 years ago
Nice find Paul - I was just about to post the same thing.For reference:- qt calls mRegion.contains(rect);- windows calls RectInRegion(mRegion, &trect)- mac calls RectInRgn(&macRect, mRegion)

Comment 17

16 years ago
So to summarize where we're at, the problem can temporarily be fixed by removing the call to ConstrainClippingRegion in nsRenderingContextBeOS::UpdateView(). In this case, no drawing disappears, but looking at drop down boxes, list views, etc. there are visible problems where the drawing hasn't been clipped. So for some reason the clipping region is occasionally wrong. One thing I tried was calling ConstrainClippingRegion(NULL) in UpdateView() before applying the new region, but this didn't work. Technically though, it looks like it would be necessary - otherwise you would be further reducing the current region with the new one (basically intersecting them). Could someone please check whether the clipping is taking place in the correct units (i.e. pixels)?

Comment 18

16 years ago
I was dumping the BRegion last night, to see if anything was a little "odd".  I
did not notice anything, but, the values did seem to be in pixels.

Comment 19

16 years ago
I will try to implement missing IsEqual, and ContainsRect as "total inclusive"
check to see what happens.
Though, Be API for regions is quite poor. So it may need some work.
Btw, previous playing with ContainsRect solved here problems with:
(missing "statical" buttons, so defects appearing on redraw only (like scrolling)
but not for renmaining sites which seems using (JS) layers or some other more
sofisticated technique

Comment 20

16 years ago
When I was dumping the information about each region. NONE of the regions were
complex, i.e. only single rectangles.

Comment 21

16 years ago
OK, my fellows!
It seems that bug is found!
Problem is with "nullregion". It is valid nsRegion with aX==aY==aWidth==aHeight==0.
But in BRegion it results in region with single BRect with
Frame().Width()==Frame().Height() = -1;

Thats not so big problem, but problem (and there is remedy) is
nsRegionBeOS::SetRegionType() implementation - it autoassigns mRegion with
RectsCount == 1 to type eRegionComplexity_rect which is definitely wrong.
Setting it for this case to eRegionComplexity_empty fixes our problem.

So i'm going to check if there any side-effects and submitting patch after that
(there are lot of other changes in my code, but only that one was definitive -
so trying with untouched nsRegionBeOS.cpp).

Comment 22

16 years ago
Sorry, don't care about previous post. Sending it to /dev/null.
My mistake - in reality i did same thing as Daniel - disable SetClippingRegion
at all.

But i have question - is possible that Mozilla adds rectangle to region
originating from another view?

P.S. Maybe we need better place to communicate:(

Comment 23

16 years ago
Addition to comment


fixes both problems - disappearing images, and artifacts in menus and drop-downs.	
(Also seems cured issue with stalling scrolling down in big bookmarks menu)
(As far as i remember we are using 	ConstrainClippingRegion() in 3 more places -
CopyBits in nsRenderingContextBeOS.cpp

and in OnPaint() + Scroll() in nsWindowBeOS.cpp

maybe some of them is overhead?

Comment 24

16 years ago
Paul, Daniel, can you test? - solution from previous comment

fixed also famous long-time bug about buggy scrollbars here
( )
If it is case for you, we should set dependency or duplication.

Comment 25

16 years ago
Sergei, this does the same thing as my change (commenting out the line completely). Either way, the drawing problems disappear, BUT new problems come up. For example, go to the Apple online store and try to configure a PowerBook, for example. You'll notice that if you play with the drop down boxes there to choose different options, sometimes the string will draw outside of its bounds. I've seen similar problems with text boxes on other sites too. In other words, turning off clipping completely is not a good solution either. We need to fix the clipping region instead.

Comment 26

16 years ago
Daniel, it may be not just the same, because in my case it cleans
ClippingRegion, which  maybe was set by 3 other instances of ConstrainClipping
Region mentioned above.
So i don't see yet any such hard issues.

But maybe we can do something alike:
in UpdateView:

Comment 27

16 years ago
Daniel, it may be not just the same, because in my case it cleans
ClippingRegion, which  maybe was set by 3 other instances of ConstrainClipping
Region mentioned above.
So i don't see yet any such hard issues.

But maybe we can do something alike:
in UpdateView:
instead existing code,

and set clipping in nsRenderingContextBeOS::SetClipRegion in Windows port manner
- something alike:
NS_IMETHODIMP nsRenderingContextBeOS :: SetClipRegion(const nsIRegion& aRegion,
nsClipCombine aCombine, PRBool &aClipEmpty)
	BRegion *rgn, *currgn;
	rgn = currgn = nsnull;
	int  cmode, cliptype;

    aRegion.GetNativeRegion((void *&)rgn);
	if (rgn && currgn && mView)
		switch (aCombine)
			case nsClipCombine_kIntersect:
		    case nsClipCombine_kUnion:

		    case nsClipCombine_kSubtract:

    		case nsClipCombine_kReplace:
        		currgn = rgn;

    	return PR_FALSE; 

	if (currgn->Frame().IsValid())
    	aClipEmpty = PR_TRUE;
    	aClipEmpty = PR_FALSE;

	return NS_OK;

instead existing implementation.

P.S. Which browser you use? Your posts are non-wrapped, like ones posted from

Comment 28

16 years ago
Daniel, little notice and question.
With code as is (ConstrainClippingRegion(region), obscured images appears when
you MOVE some other window over this disappeared image.
But don't if yoy hide Mozilla under some other window, and then activate Mozilla

As i understand, Clipping region is thing for AppServer to deal with. But in one
case it affects redrawing, in other don't.

So maybe nsRegion code is ok, but we just don't call UpdateView when it supposed
to be called, so it don't update ClippingRegion via UpdateView when it supposed,
or just ignore some events?

Comment 29

16 years ago
addition to app_server notice (my previous comments):
This code in UpdateView - 
		if (mClipRegion ) 
			mClipRegion->GetNativeRegion((void *&)region);
does job very nice for me - no obscured images, bo artifacts, nice listboxes in

Comment 30

16 years ago
I have suspects that reported in some other bugs disappearing caret in text
fiels (not the bug about too lefty 0-position) may be also related to this problem.

Comment 31

16 years ago
Created attachment 109359 [details] [diff] [review]

This is a patch based on Sergei's comments.  It really does seem to work.  I
have not seen any problems, and, works with the test Daniel had sent me.
And yes, it does seem to fix the missing caret problem.  (I've tried my
damndest to make it diappear, and it hasn't yet :-) )

Comment 32

16 years ago
Paul, a few problems here. First, there's no reason to get the native region if you're going to be setting it to NULL. Second, there's a typo in ConstrainClippingRegion(0) in your patch. But the big problem is that some drawing is no longer clipped. Try choosing an optional display from the Apple Store when configuring a PowerBook for example.

Comment 33

16 years ago
Created attachment 109361 [details]
Screen shot

This shows that text was not clipped properly in both the drop down box for
choosing a monitor, as well as the top URL bar.

Comment 34

16 years ago
I also noticed problems with text in URL and some other places, Daniel, but that
is more weird problem than you imagine.

Text now don't go to wrap in some situation where it supposed to do so.

It looks like that some boundaries were reported according to native clip region
set (in some other place in Mozilla "higher-level" code), and maybe this is the
reason for missing wrapping. 

Comment 35

16 years ago
Little addition about this "non-hidden" text.

It behaves now JUST in oppoite way to disappeared images in comment

 - if you move SLOWLY some window over this "extra" text - you can erase it, so
all looks OK. But you cannot erase it by obscuring under another window - and
erased text goes visible again when you bring Mozilla window to front.
And also - you cannot erasi it totally, if you move "eraser" window too fast.

Comment 36

16 years ago
I wish Daniel provide me with other than URL-bar and AppleStore examples for
exceeding text arising in case of patch.

Both are same case - very annoying for BeOS hybrid object - drop-down box.

Problem is - those objects consist of BView belonging to top-level window and
separate window (created as eWindowType_popup) window. (So if you look at
BWindows list in AplleStore case, as for any window with drop-down boxes, e,g,
on BeZilla page, you can see bunch of w-> threads)

I have feeling that here appears again famous contradiction between BeOS and
remaining world - windows are in separate thread (and so at different loopers),
and popup window don't belong to window where "first item of list" is placed.
And i'm afraid that somewhere it wasn't took in account, so some Mozilla's
paint/update/drawing-setting message pass to such object only once, for object
as whole. Which is insufficient in BeOS case.

Comment 37

16 years ago
Found "ideal" solution for nsRenderingContextBeOS.
Just like each UpdateView() is balanced with UnlockLooper(), same way (almost)
each  UpdateView should be also balanced with ConstrainClippingRegion(0) in
drawing primitives (befor UnlockLooper).

No disappeared images, no strings with broken Z-order.

Patch should be

Comment 38

16 years ago
Comment on attachment 109359 [details] [diff] [review]

Attachment #109359 - Attachment is obsolete: true

Comment 39

16 years ago
Created attachment 109825 [details] [diff] [review]
patch for testing

Creating pair for UpdateView() - UnlockViewLooper() and replacing
mView->UnlockLooper() with it.

Though, i dislike current form and name of UpdateView - i prefer something like

bool LockAndSetView(BView *)
bool retvalue;
 if((retvalue =(mView && mView->LockLooper))) {
 return retvalue;

and same for this new function.

Comment 40

16 years ago
New inestigation (as comment for previous patch) - it seems that
ContstrainClippingRegion(0) before UnlockLooper is needed only in 

NS_IMETHODIMP nsRenderingContextBeOS::DrawString(const char *aString, PRUint32
	nscoord aX, nscoord aY, const nscoord *aSpacing).

It seems related to double draw mode change in this function.

Comment 41

16 years ago
Ohh, it appears that since spring of 2001 DrawImage and DrawTile is outside
nsRenderingContext in reality. in ns*Image.cpp.
Which does sets clipping and other things independently. And hasn't UpdateView
I suspect some collisions there.

Comment 42

16 years ago
Created attachment 110178 [details] [diff] [review]
Patch for DrawString

Anyway, submitting patch which fixes mentioned problems for me.
Inspite it seems more like hack.


16 years ago
Attachment #109825 - Attachment is obsolete: true

Comment 43

16 years ago
it seems there really are another clipping mistakes, supposedly related to
nsImage.cpp methods - for example on background image
for submit buttons (on right) spreads itself above this button even with applied

Comment 46

16 years ago
Not just buttons either with not enough clipping. Like one of the bugs you've
linked to, images in table cells sometimes spread outside of their bounding
boxes (the fire animation in the tinderbox does this, as well as viewer demos 3
and 4). This is on a trunk nightly from 4 December, so no patches.

Also, I don't like the ConstrainClippingRegion(0) thing - it feels like a hack
to me.

BeOS gfx is still slow, and there are now quite a few bugs (scrolling,
disappearing images, also -moz-opacity seems to make things completely
invisible). What we really need is a full rewrite, after deciding on a much more
efficient looper-locking mechanism. We can implement it with just speed in mind
(using aFontID and GetWidth and things to speed rendering, for example). Plus,
the bugs with clipping would probably be fixed during this process.

What does anyone think?

Comment 47

16 years ago
A rewrite would be nice, but the total lack of documentation makes that very difficult. It's the main reason I'm not contributing to the project anymore. There is no explanation of how the graphics subsystem works, who owns what, how the double buffering and scrolling operate, what the coordinate system assumptions are, etc. All you get are one or two sentences above methods in the interface headers, things like "nsImage::Optimize() optimizes the image". Having said all that, I think that the BeOS widget code is even more broken than the gfx code. Text boxes, scrollbars, and drop downs all still have problems. Plus there's no drag-and-drop, no printing, and other higher-level features that people miss. In my opinion, the disappearing images is a priority, but apart from that the gfx implementation is acceptable enough to leave alone for a while, and fix bugs elsewhere.

Comment 48

16 years ago
I know there isn't a lot of documentation, I've been trying to find it for the
last couple of weeks. As you say the interface headers aren't particularly
helpful (a bit like Microsoft's .net help: "IsNavigable sets whether or not the
data grid is navigable"). However there are plenty of other platform gfx
implementations to look at - most of the purpose of the functions can be guessed
from this. Side note: is there a reference platform with everything implemented?
GTK, Windows?

I guess it depends on your system how important the gfx speed is. On my lowly
K6/2 450 it is usable enough to be my fulltime browser, but a lot slower than
moz on windows (or even IE). Slow enough that I have to quickly switch to a
different workspace and fire up soundplay or something to remind me I'm running
BeOS. Getting to the bottom of the images problem would be a good excuse to try
a new, fast gfx implementation. There's plenty of other stuff that needs doing
too, of course. But if we could get a 10x gfx speedup, I could live with
scrollbars that sometimes appear when they shouldn't and not having any printing ;)

Comment 49

16 years ago
Anyway, i'm doing gfx revision now. Some things are obsolete, far behind time.
E.g. in nsImageBeOS DrawToImage code was too old and caused big processor load
on animated images.
Also there were two version of DrawTile (background painting method) - and only
one of them exists now in other ports and even in public definition.

And more, seems here, in nsImageBeOS, is just reason for this bug: for quite
long time Mozilla uses DrawImage and DrawTile from nsImage instead
nsRenderingContext - and DrawImage in nsImageBeOS lacks
ConstrainClippingRegion(rgn) (all drawing methods in nsRendering contain it via
UpdateView). Once added, it fixed bug.

Comment 50

16 years ago
Does this fix all clipping problems - both disappearing images and images
spreading outside their bounding box? What about text box carets?

I guess this means ConstrainClippingRegion(0) is no longer needed. That would be
great, I was never happy with that as a permenant fix.

Comment 51

16 years ago
1)I didn't see bugs with viewer demos 3 and 4 for long time
2) I don't use ConstrainClippingRegion(0) in UpdateView(). Only place where it
was added in my code, as i noticed in one of comments - end of DrawString
functions. But now i removed it even from there.
3) Patch for polygons fixed part of caret problem in single-live fields for me,
but ther is another problem, related to focus/activation events, when caret
sometimes don't appear on field on mouse click - it appears there after some
keyboard input - and if you delete all input - cret is still visible in ultimate
left position

Comment 52

15 years ago
"mass" re-assigning of bugs from pav to myself
Assignee: pavlov → jdunn

Comment 53

15 years ago
*** Bug 125477 has been marked as a duplicate of this bug. ***

Comment 54

15 years ago
Patch for
obsoleted this problem.
Mozilla now uses XUL-scrollbars.
But problem is about status - should it be FIXED ? WONTFIX?
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 55

15 years ago
oops, closed wrong bug, reopening
Resolution: FIXED → ---


15 years ago
Depends on: 218134

Comment 56

15 years ago
*** Bug 201536 has been marked as a duplicate of this bug. ***

Comment 57

15 years ago
Created attachment 138338 [details] [diff] [review]
very important patch

Fixing this most long-standing, most awful and annoying BeOS GFX bug.
I think there are lot of several dups of it on bugzilla.

Problem was explained in

To solve problem  in unified with nsRenderingContextBeOS way, i made former
UpdateView() public (like UpdateGC in gtk port), changed it to bool (in order
to return test results for mView existance and its locked state) and changed
this function name to LockAndUpdateView().

Then used this LockAndUpdateView() in nsImageBeOS Draw() and DrawTile()


15 years ago
Attachment #110178 - Attachment is obsolete: true

Comment 58

15 years ago
Comment on attachment 138338 [details] [diff] [review]
very important patch

review request
Attachment #138338 - Flags: review?(timeless)

Comment 59

15 years ago
Patch seems to solve many graphics problems. Works much better when scrolling.
No redraw-problems. Couldn't spot any rendering problems at all in fact.
Comment on attachment 138338 [details] [diff] [review]
very important patch

+	//LockAndUpdate() sets proper clipping region here and elsewhere in
+	if(((nsRenderingContextBeOS&)aContext).LockAndUpdateView()) {	

the comment should say LockAndUpdateView, not LockAndUpdate, apparently

+	}

is this a -w patch? otherwise, the indentation here is wrong.

Comment 61

15 years ago
yeah, i did diff -uwp.
Should i use different diff flags set?


15 years ago
Attachment #138338 - Attachment filename: nsImageBeOS.patch → nsImageBeOS.patch, diff -uwp
Assignee: jdunn → arougthopher
Component: ImageLib → GFX: BeOS
QA Contact: tpreston → timeless

Comment 62

15 years ago
Created attachment 138385 [details] [diff] [review]
Patch (diff -up)

Comment changed.
type of LockAndUpdateView() changing to bool (to be compatible with
BView::LockLooper in return value and to look C/C++ "native" when used in


15 years ago
Attachment #138338 - Attachment is obsolete: true

Comment 63

15 years ago
Comment on attachment 138338 [details] [diff] [review]
very important patch

removing review request from obsoleted patch
Attachment #138338 - Flags: review?(timeless)

Comment 64

15 years ago
Comment on attachment 138385 [details] [diff] [review]
Patch (diff -up)

review request
Attachment #138385 - Flags: review?(timeless)

Comment 65

15 years ago
Created attachment 138389 [details] [diff] [review]
patch -up with new comment

Added large comment (by biesi request) about LockAndUpdateView() method
Attachment #138385 - Attachment is obsolete: true
Comment on attachment 138389 [details] [diff] [review]
patch -up with new comment

marking r=timeless from irc
Attachment #138389 - Flags: review+


15 years ago
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.