Closed
Bug 74313
Opened 24 years ago
Closed 23 years ago
Impossible to display an image at other than intrinsic size (can't resize dynamically or in <img> tag)
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9.3
People
(Reporter: bzbarsky, Assigned: tor)
References
Details
(Keywords: regression, testcase, Whiteboard: [imagelib] [linux scaling] wanted for 0.9.1)
Attachments
(5 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
BUILD: linux build from 2001-04-01
STEPS TO REPRODUCE:
Try to resize a GIF in JavaScript by setting it's width/height
EXPECTED RESULT:
The image is resized.
ACTUAL RESULT:
The image does not change size and parts of it go black.
NOTES:
Building with --disable-libpr0n fixes this behavior. So assigning to pavlov.
Reporter | ||
Updated•24 years ago
|
Blocks: autoresize
Comment 1•24 years ago
|
||
Does this also affect resizing images in Composer's image dialog?
Reporter | ||
Comment 2•24 years ago
|
||
Just tried composer. When the image is resized there (I tried a gif I had lying
around) the box in the document is resized correctly but the image itself is not
shown. You get an empty box.
This affects both the image itself when a size different from the native size is
specified and the "preview" thumbnail in the image creation dialog -- that
thumbnail image is not present in builds with libpr0n enabled.
Comment 3•24 years ago
|
||
your build probably doesn't have XIE or gdkpixbuf so images arn't scaling.
Reporter | ||
Comment 4•24 years ago
|
||
Hmm. I _was_ trying this on an X server with no XIE. I just tried one with XIE
and a simple testcase and I get the same results. I can't check composer right
now due to bug 74707
Steps to reproduce:
1) Go to http://web.mit.edu/bzbarsky/www/Graphics/Dilbert/dogbert.gif
2) Type javascript:dump(document.getElementsByTagName("img").item(0).width=400)
The image turns mostly blank and does not resize.
I am certain that I have XIE -- xdpyinfo lists it, and I see the XIE_Flo crasher
in libpr0n....
Comment 5•24 years ago
|
||
Works fine on MacOS
Comment 7•24 years ago
|
||
Comment 8•24 years ago
|
||
Also works on MacOS, although I see odd garbage on the bottom of the larger ones
(different bug).
Reporter | ||
Comment 9•24 years ago
|
||
Leston's testcase makes this "major".
Severity: normal → major
Keywords: testcase
Summary: Impossible to resize GIFs in JS → Impossible to display a GIF at other than intrinsic size (can't resize dynamically or in <img> tag)
Reporter | ||
Comment 10•24 years ago
|
||
*** Bug 75159 has been marked as a duplicate of this bug. ***
Comment 11•24 years ago
|
||
This error is also occuring on Irix
Comment 12•24 years ago
|
||
Pav, didn't you write a basic scaling funct for linux where we don't have
everything installed?
Reporter | ||
Comment 13•24 years ago
|
||
I have tested this a bit mode. The problem Leston describes is indeed only
present with no XIE. But even with XIE present we fail to properly resize GIF
images with transparent backgrounds. bug 75351 filed on that issue.
Reporter | ||
Comment 14•24 years ago
|
||
*** Bug 75314 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
the summary's not quite accurate here - I see the same behaviour
with JPEGs as well. It's a most irritating problem - it also affects
<INPUT TYPE="IMAGE">, and breaks any page where someone's not quite
got the image size correct.
(the note about needing XIE - well, the RH6.2 boxes here don't seem to
have this loaded by default. I'd guess there's rather a lot of boxes
out there with this distro...)
Comment 17•24 years ago
|
||
Added myself to cc-list.
shouldn't this bug be nscatfood+? and have a target milestone of .9 (if that's
feasonable ofcourse) or atleast 1.0?
Updated•24 years ago
|
Whiteboard: [imagelib] → [imagelib] [linux scaling]
Reporter | ||
Updated•24 years ago
|
Summary: Impossible to display a GIF at other than intrinsic size (can't resize dynamically or in <img> tag) → Impossible to display an image at other than intrinsic size (can't resize dynamically or in <img> tag)
Reporter | ||
Comment 18•24 years ago
|
||
*** Bug 75903 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 19•24 years ago
|
||
*** Bug 76658 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
Comment 22•24 years ago
|
||
ok, here is a patch...
first thing:
We always try and use XIE before gdkpixbuf. This is for 2 reasons... first
because gdkpixbuf currently isn't scaling alpha masks and therefore makes images
with alpha masks that are scaled look pretty dumb. Secondly, XIE should, in
theory, allow the scaling to happen on the X server resulting in less data going
back and forth between the client and server.
second thing:
try to use gdkpixbuf to scale... this is buggy and doesn't love me.
third thing:
do scaling using the data on the X server by doing XGetImage and XPutImage..
supports alpha masks, but is slow as shit running remotly with large images.
most of this is from syd. it could probably be sped up locally by trying to use
XShm*Image calls.
four thing:
this patch has code that should be able to take the client data and scale it...
that code doesn't love me and doesn't work very well. feel free to make it
better.
this patch isn't perfect, but X not having scaling built in makes my life suck.
Status: NEW → ASSIGNED
Reporter | ||
Comment 23•24 years ago
|
||
Is it worth checking this into the branch once it's cut and working on a better
fix for the trunk?
Or is this the best option we'll have for a while?
Reporter | ||
Comment 24•24 years ago
|
||
*** Bug 75768 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 25•24 years ago
|
||
*** Bug 75920 has been marked as a duplicate of this bug. ***
Comment 26•24 years ago
|
||
Wow, it's amazing to find out how many sites use scaled images ...
Comment 27•24 years ago
|
||
*** Bug 75105 has been marked as a duplicate of this bug. ***
Comment 28•24 years ago
|
||
The Xlib version is going to work fairly well for a majority of users. Those who
are running X remotely however will want to set up their X server to support XIE
(if not already set up).
Comment 29•24 years ago
|
||
*** Bug 74388 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 30•24 years ago
|
||
*** Bug 77143 has been marked as a duplicate of this bug. ***
Comment 31•24 years ago
|
||
*** Bug 75892 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 32•24 years ago
|
||
*** Bug 77174 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 33•24 years ago
|
||
The patch is missing scale.c.
Comment 34•24 years ago
|
||
Comment 35•24 years ago
|
||
tor@cs.brown.edu,blizzard@mozilla.org -- could you provide r= and sr= for this?
Thanks.
Assignee | ||
Comment 36•24 years ago
|
||
[s]r=tor
syd is looking at a faster implementation of the ScaleImageNN function.
pav, file a bug about not scaling 8-bit alpha images properly.
Comment 37•24 years ago
|
||
77266 filed for 8bit alpha scaling
Comment 38•24 years ago
|
||
r=pavlov on syd's patch of the patch.. syd: can you r= the rest of it?
Comment 39•24 years ago
|
||
r=syd
Comment 40•24 years ago
|
||
a= asa@mozilla.org for checkin to 0.9
Comment 41•24 years ago
|
||
is there a bug filed on making the scaling stuff faster? syd? if not, lets get
one filed.
marking this one fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 42•24 years ago
|
||
This doesn't seem quite fixed yet (though it's getting there). When i open the
testcase, none of the non-intrinsically-sized images are painted at first. The
only way to make them appear is to scroll down (down only, not up), making the
image's space disappear under the toolbar and then scroll back down. Only the
portion of the image past which i have actually hidden is actually rendered (so
there's no way to view such images near the bottom of the page). Resizing the
window can make some of these images disappear again, too. (Again, only the
non-intrinsically-sized ones.)
Please reopen. (I don't seem to have the authority to do so.)
Comment 43•24 years ago
|
||
Sounds like bug 76046 to me, not this bug.
Comment 44•24 years ago
|
||
The problem i'm seeing seems to be a bit different from the behaviour seen on
the URL for bug 76046. It differs in the following ways:
1. This problem effects only resized images (see testcase),
while 76046 affects images in their intrinsic size (see
URL at that bug). Load this bug's testcase several times,
varying the window size. The behaviour is consistent: the
instrinsically sized images render perfectly, while the
resized ones appear only by first hiding them at the top of
the pane by scrolldown. The URL for bug 76046 uses a large,
intrinsically sized jpeg.
2. With this problem, the bottom of the image does not become visible
by scrolling down, while this is the behaviour of 76046.
In other words, in this bug, the hidden bottom part of the
image seems to not be rendered at all, while in 76046 the
hidden bottom part appears by scrolling.
The behaviours seem different. I don't know if you want 76046 so subsume the
behaviour i've described here. Does it appear likely that both bugs would be
solved with the same fix?
Comment 45•24 years ago
|
||
there is a seperate bug for images not drawing the first time... i don't recall
the number off the top of my head, but it is there in my vastly large bug list.
Comment 46•24 years ago
|
||
*** Bug 78228 has been marked as a duplicate of this bug. ***
Comment 47•24 years ago
|
||
*** Bug 80174 has been marked as a duplicate of this bug. ***
Comment 48•24 years ago
|
||
*** Bug 79919 has been marked as a duplicate of this bug. ***
Comment 49•24 years ago
|
||
*** Bug 79888 has been marked as a duplicate of this bug. ***
Comment 50•24 years ago
|
||
Still can't see the images C through F on linux build 2001052112
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 51•24 years ago
|
||
*** Bug 80503 has been marked as a duplicate of this bug. ***
Comment 52•24 years ago
|
||
untargetting my reopened imglib bugs to investigate.
Target Milestone: mozilla0.9 → ---
Comment 53•24 years ago
|
||
*** Bug 78573 has been marked as a duplicate of this bug. ***
Comment 54•24 years ago
|
||
*** Bug 82610 has been marked as a duplicate of this bug. ***
Comment 55•24 years ago
|
||
Adding self to CC list. Any idea on a target milestone?
Comment 56•24 years ago
|
||
*** Bug 81713 has been marked as a duplicate of this bug. ***
Comment 57•23 years ago
|
||
*** Bug 82378 has been marked as a duplicate of this bug. ***
Comment 58•23 years ago
|
||
*** Bug 83098 has been marked as a duplicate of this bug. ***
Comment 59•23 years ago
|
||
Pav, have you had a chance to look into this? It's going to make 0.9.1 a rather
unpleasand release for linux users.
Status: REOPENED → NEW
Whiteboard: [imagelib] [linux scaling] → [imagelib] [linux scaling] wanted for 0.9.1
Comment 60•23 years ago
|
||
Actually Asa the 0.9.0 release was much worse than this.
libpr0n on Unix was basically completely unusable when it went in. Progress from
there is slow, and Pav has other priorities.
Is Linux an important platform for Mozilla? The 0.9.0 release says "No" and a
lot of people heard it.
Comment 61•23 years ago
|
||
*** Bug 78700 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 62•23 years ago
|
||
Something odd is happening to the clip region of the rendering context. If
you replace copyGC from the context with a gdk_gc_new() in
nsImageGTK::DrawScaled() then the images are drawn as expected.
Comment 63•23 years ago
|
||
*** Bug 83456 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 64•23 years ago
|
||
*** Bug 83523 has been marked as a duplicate of this bug. ***
Comment 65•23 years ago
|
||
*** Bug 83312 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9.3
Comment 66•23 years ago
|
||
Actually, i think mozilla's most important platform is linux. Since most
webpages are made with IE in mind, i really dont think windows users are going
to switch to mozilla. Netscape 6 arrived, and it sucked big time. Netscape 4.77
is there, but it's motif-based (ug) Opera is not really free, but ad-sponsored.
So that gives me only 2 choices: mozilla and konqueror
I think 0.9 is fine, but we are getting too many new bugs and regressions on
this builds. I am currently using 2001053021 because it's the last version that
autocomplete works, but it also breaks the delete key in mail. I posted bug
82278 corcening how slow mozilla renders images.
http://www.digitalblasphemy.com/dbgallery/4/morninglight.shtml is an example
I have been told this is an issue of this bug. Now look at this one:
http://www.angelfire.com/hi/CristianCastro/
That chokes on my 1200mhz system
This is really a major bug
Comment 67•23 years ago
|
||
*** Bug 83716 has been marked as a duplicate of this bug. ***
Comment 68•23 years ago
|
||
*** Bug 84810 has been marked as a duplicate of this bug. ***
Comment 69•23 years ago
|
||
*** Bug 84859 has been marked as a duplicate of this bug. ***
Comment 70•23 years ago
|
||
I've just deleted 0.9.1 (talkback) and downgraded to 0.8 due to this bug.
Please change target milestone to 0.9.2, or even better: make a quick fix
soon. You will lose some Linux users if this bug remains much longer.
Comment 72•23 years ago
|
||
petersen@netscape.com filed a parser bug that appears to be this. Bug 84782
Is it all parser, not imagelib?
Comment 73•23 years ago
|
||
It can't be all-parser, not least because the
problem seems to be X11-only. 84782 sure looks
like a dup.
Comment 74•23 years ago
|
||
*** Bug 84782 has been marked as a duplicate of this bug. ***
Comment 75•23 years ago
|
||
In imagelib there are at least two bugs causing these problems:
1) scaling too much
2) clipping rect is in wrong position
I am working a patch for this.
Comment 76•23 years ago
|
||
the url in dup bug 83312 is a great testcase:
http://www.sj-arena.com/
Notice how image clipping varies when one resize width of browser window.
Comment 77•23 years ago
|
||
*** Bug 81571 has been marked as a duplicate of this bug. ***
Comment 78•23 years ago
|
||
Have you noticed what happens when you put the mouse on top of the mozilla
window of this bug? Notice the big black square caused by the <img>
This is just weird...
Comment 79•23 years ago
|
||
Comment 80•23 years ago
|
||
*** Bug 85086 has been marked as a duplicate of this bug. ***
Comment 81•23 years ago
|
||
In my earlier comment I meant GTK/XIE - not ImageLib.
For some reason XIE didn't respect clip origin so I had to use XChangeGC()
function to set it. Also DoFlo() used wrong size for the source area which
caused those blue images.
Now I go to get some sleep before it is morning.
Comment 82•23 years ago
|
||
Wowsa :)
Buildt with the patch and tested some dups.
These are fixed:
bug 74861, bug 75159, bug 75314, bug 75903, bug 75768, bug 75105
bug 74388, bug 77174, bug 83312
bug 76658 - URL is now a 404
bug 75105 - Page has changed - no image there anymore.
Various result:
Bug 77143: All images load, but a resized "blank.gif" shows as a black area.
Looks like another bug.
In other cases a 1x1 scaled gif gets an unintended outline
( for instance left side at http://www.arlut.utexas.edu/ )
Comment 83•23 years ago
|
||
Could you check 82278 with the new build as well?
Comment 84•23 years ago
|
||
There are still some issues with the patch
testcase: http://211.9.115.254/text.html
This is not entirely XIE's fault but that image should have transparent background.
Comment 85•23 years ago
|
||
Comment 86•23 years ago
|
||
*** Bug 82529 has been marked as a duplicate of this bug. ***
Comment 87•23 years ago
|
||
*** Bug 83308 has been marked as a duplicate of this bug. ***
Comment 88•23 years ago
|
||
http://www.newsforge.net is another site where a 1x1 pix.gif used for scaling
grey lines under stories get an outline - in this case the outline is visible on
right and left side only. I think the fix in Asko's patch is correct though -
merely revealing a few other little problems we weren't seeing till now.
Comment 89•23 years ago
|
||
on the other hand.. perhaps it shouldn't be checked in till the black
transparent gif bugs are solved. http://industry.java.sun.com/ looks pretty
bad.. huge black sqares scattered around on page.
Comment 90•23 years ago
|
||
*** Bug 85137 has been marked as a duplicate of this bug. ***
Comment 91•23 years ago
|
||
I think this is the bug I'm seeing...
With 0.9.1 build on Linux (tar.gz downloaded from mozilla.org) and gdkpixbuf
installed, I see all images scaling fine *except* any gif that has a transparent
background, which just don't display at all. Is that this bug or something else?
(I didn't think XIE was even used if gdkpixbuf was installed at runtime...)
Comment 92•23 years ago
|
||
With the 0.9.1 tar.gz from mozilla.org, this bug happens with transparent GIFs
or PNGs. JPEGs scale fine (modulo a nasty performance hit on scrolling). I
mentioned this in bug 84859 (as well as attached test case), which was marked as
a duplicate of this one.
Comment 93•23 years ago
|
||
I reported the slow speed in scrolling on bug 82278
Comment 94•23 years ago
|
||
I just REOPened bug 75351 for the linux-disappearing-transparent-scaled-images
issue. As far as I'm concerned it doesn't seem to match the symptoms described
in this bug (which also covers JPEGs and non-transparent images), so hopefully
it won't just get blindly DUPed.
Probably there was a better bug to REOPen, but that was the best that I could
find at the time.
Comment 95•23 years ago
|
||
Comment 96•23 years ago
|
||
Should fix those black transparent gifs.
Comment 97•23 years ago
|
||
Its possibly, that bug 85137 is duplicate of this... Expect one interesting
moment... if you type http://www.amber-da.com.ua you can see in left down corner
the image (animated) with current tempereture and time. This is the same image
as in my test page writing for bug 85137 illustration. In this place image like
whell. But in my example is not. And a differences is - in example where its not
work all images are in table. I vas try to change hight and width attributes in
image and its work whell... But in tables - not... Possibly my 85137 is a
dupe... but...
Comment 98•23 years ago
|
||
Built with the new patch and running for an hour or so testing dups here:
Images seem to now render perfect :)))
Newsforge and Sun sites: former "black squares" are scaled correctly and
transparent again.
This seems ready for r/sr/a
Comment 99•23 years ago
|
||
*** Bug 84996 has been marked as a duplicate of this bug. ***
Comment 100•23 years ago
|
||
*** Bug 85052 has been marked as a duplicate of this bug. ***
Comment 101•23 years ago
|
||
Seems so. I pulled at around 21:30 and then patched with attachment 37942 [details] [diff] [review]
Comment 102•23 years ago
|
||
comments or r/sr= needed.
Comment 103•23 years ago
|
||
went to http://web.mit.edu/bzbarsky/www/Graphics/Dilbert/dogbert.gif
and resized the gif with javascript.
Works fine
Linux 2001061306
Comment 104•23 years ago
|
||
http://www.sj-arena.com/ is still WAY broken :(
Comment 105•23 years ago
|
||
Francisco León:
It renders perfect here with the patch. Which compiler are you using? (version
too, please.)
Comment 106•23 years ago
|
||
I thought patch was in nightly's already (oops)
Using 2001061306
Comment 107•23 years ago
|
||
could anyone with the applied patch from attachment 37942 [details] [diff] [review] try this url
http://www.hehe.at/funworld/archive/bugzilla.html
I've applied the patch to the nightly source (13 Jun 01) but something is screwd
up here; the above url doesn't work; http://www.sj-arena.com/ seems to be ok;
testcase from attachment 29872 [details] works partly while on the nightly binary build
C through F do not render at all, with the patch applied D and F are rendered
wrong (ie D shows the half picture, F shows a quarter) C and E are shown correct
[well I guess I should "clean up" my system a bit ;) but anyway it would very
helpfull for me to know if it works and the strange effects only happen
here](sorry for the bad english 4AMversion %)
Comment 108•23 years ago
|
||
*** Bug 85821 has been marked as a duplicate of this bug. ***
Comment 109•23 years ago
|
||
Peter Bergt:
With the patch the attachment 29872 [details] works for me.
http://www.hehe.at/funworld/archive/bugzilla.html is showing
different problem than the patch is trying to fix:
WARNING: can't do 8bit alpha stretched images currently
, file nsImageGTK.cpp, line 464
8bit alpha stretched images are NOT supported by Mozilla at this time.
Comment 110•23 years ago
|
||
Could anybody explain how is this bug related to bug 83920 (remove XIE)?
The XIE support will be droped by XFree86 and it's using is deprecated by
XFree86 team. libXIE is not included in current Red Hat Rawhide Linux
(XFree86-4.1.0).
This patches looks like still using XIE, is it appropriate to work on this as it
looks now XIE will be dropped/removed from Mozilla?
Comment 111•23 years ago
|
||
Martin, bug 83920 has no recent (last few days) activity. We are up against a
very tight deadline for 0.9.2, and if XIE is still going to be in Mozilla 0.9.2
then it needs the scaling patch before we get buried in DUPEs.
Sometimes it is appropriate to check in a fix even though your crystal ball
tells you that the code will get ripped out again in a week or a month - and
this is one of those times.
Comment 112•23 years ago
|
||
(using latest CVS on GNU/Linux i386 with latest patch)
At http://www.standaard.be there is scaled down image in the middle of the page.
This image is still not rendered in the page. Opening the image seperately works
fine.
I already reported this elsewhere, but someone decided it was a dupe of this bug.
Comment 113•23 years ago
|
||
Regarding http://www.standaard.be/
if you mean f140601b.jpg, it renders OK here in linux builds both with and
without the patch. I compared nightly 2001061308 and a current CVS with the
patch, against what is visible in NC4.77: All show the same images.
Comment 114•23 years ago
|
||
the test case looks here like this
http://www.hehe.at/mozilla/bugzilla-test-case.jpg (ie D and F don't render
correct)
nightly source (2001/06/13) with patch, gcc 2.95.2, glib/gtk 1.2.10
some warnings from mozilla:
WARNING: alpha bitmask not scaled!
, file nsImageGTK.cpp, line 487
Comment 115•23 years ago
|
||
I built with the patch, and tested some dups:
bug 82378 http://www.sharkyextreme.com/
bug 81571 http://www.suggestafix.com/about.html
These both worked well once I turned on the XIE extension in X.
Without XIE (and I'm pretty sure I don't have gdk_pixmap), most of these are
still broken with or without the patch. Is there another bug that covers the
changes needed for the xlib version?
Peter, I suspect that's the gdk_pixmap clipping problem you're seeing. Looks ok
here.
TGke, do you have the XIE extension turned on in your X server?
xdpyinfo |grep XIE will show XIE if it's enabled.
Comment 116•23 years ago
|
||
about http://www.standaard.be
I suppose I was still asleep when I tested that. The current CVS version with
patch works fine, I haven't tested it without the patch, but I assume you are
right. Sorry for the hassle.
Comment 117•23 years ago
|
||
So far, the patch in bug 83920 is working great for me on the various testcases
in here. It doesn't need XIE or gdk_pixmap. I suggest trying it.
Comment 118•23 years ago
|
||
Yes, please take the time to test the patches in 83920. They are working really
well for me as well and the more testing the better.
Comment 119•23 years ago
|
||
*** Bug 86046 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 120•23 years ago
|
||
*** Bug 86162 has been marked as a duplicate of this bug. ***
Comment 122•23 years ago
|
||
*** Bug 64590 has been marked as a duplicate of this bug. ***
Comment 123•23 years ago
|
||
*** Bug 80950 has been marked as a duplicate of this bug. ***
Comment 124•23 years ago
|
||
*** Bug 86512 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 125•23 years ago
|
||
Checkin for 83920 fixes this problem on the gtk port. Tested the test case
included here and about a half-dozen of the dups. Closing.
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 126•23 years ago
|
||
Verified fixed, tested most testcases and they work, scaled image rendering is
also faster
My bug 82278 is now opened up and confirmed to get some performance issues fixed
in scaled image rendering
Build 2001061821
Comment 127•23 years ago
|
||
build 2001061823
All problems, was reported by me in bug 85137 witch was marked as duplicate of
this bug are present in this build. It's dont fixed :(
The perfect life of this bug all can see at my example, writen for my bug 85137 at
http://www.amber-da.com.ua:8100/Mozilla_bugs/GraphicsTable/BadRenderingInTable.html
Thats all... Possibly it was not duplicate of this bug ?
Assignee | ||
Comment 128•23 years ago
|
||
Comment 129•23 years ago
|
||
the URLs in bug 85137 work just fine with XIE and Asko Tontti's patch here.
This is why i marked it dup of this.
Later, XIE was ripped out and another patch applied instead, and this bug was
resolved as fixed. That last patch is now in the official builds but obviously
didn't fix bug 85137, several images appear as black with that fix. I hope
remaining issues are covered in bug 86600. Reopening bug 85137 for re-evaluation.
Comment 130•23 years ago
|
||
Comment 131•23 years ago
|
||
This testcase sometimes work and sometimes not (non-deterministic):
http://kocour.ms.mff.cuni.cz/~macok/bug.html
Load the page (should be OK for the first time) and then repeatedly hit Reload.
Bottom lines of boxes are sometimes not shown. (1/2-1/3 of cases).
Red Hat Rawhide Linux/20010619xx (nightly snapshot)
Comment 132•23 years ago
|
||
Martin, please open a new bug on this issue and post the number here.
Comment 133•23 years ago
|
||
So I filled Bug 86822
regarding http://kocour.ms.mff.cuni.cz/~macok/bug.html testcase.
Comment 134•23 years ago
|
||
Please also note that resized animated GIFs still don't display. I've filed a
new bug for that under bug 86883. I have posted a test case for that at:
<http://www.fizzylogic.com/users/bulbul/mozilla-bugs/Test_Case_for_Resized_Animated_GIFs.html>
Comment 135•23 years ago
|
||
@ Leston
your test case works correct with the patch from bug 86600
Comment 136•23 years ago
|
||
Peter: try martin's testcase and report your results
Comment 137•23 years ago
|
||
on Martin's testcase most time the top line of the news box is missing
and the vertical lines are missing on both boxes
did reload it a few times but didn't get a correct box
(I'll download the latest sources and will report changes on 86822)
Comment 138•23 years ago
|
||
Marking VERIFIED since the basic problem is fixed and the remaining issues are
under different bugs.
Status: RESOLVED → VERIFIED
Comment 139•23 years ago
|
||
*** Bug 88391 has been marked as a duplicate of this bug. ***
Comment 140•23 years ago
|
||
The testcase is broken in 0.9.2 on x86 Linux: only black borders show (no ebay
logo).
Comment 141•23 years ago
|
||
I see them fine on 2001062823 (0.9.2)
Comment 142•23 years ago
|
||
Oops, the test case does in fact work fine in 0.9.2 on x86 Linux. I apologize
for the brain damage. I usually surf with the "Accept images from the
originating server only" preference checked; with images from other servers
allowed, it works fine. Ah, the virtues of public humiliation....
You need to log in
before you can comment on or make changes to this bug.
Description
•