I don't see any images at the URL, only a Flash object.
Oh, so sorry, my mistake with the ling (shame on me): http://www.street-photo.fr/fr/slideshow-des-membres/38?fold=95&name=Gekos#ja-containerwrapd-fr Or any link in this page: http://www.street-photo.fr/fr/slideshow-des-membres
Last good nightly: 2010-07-28 First bad nightly: 2010-07-29 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=beab39d49de9&tochange=b26489e73818
WFM: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:184.108.40.206) Gecko/20111212 Firefox/3.6.25 Reproduced: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0 Mozilla/5.0 (X11; Linux x86_64; rv:11.0a2) Gecko/20120127 Firefox/11.0a2 Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20120127 Firefox/12.0a1
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 9 Branch → Trunk
Thanks for this confirmation Thomas.
I do not know what i have to do in order some dev take this ugly bug in consideration. I will add it is a pity to see that Firefox, witch was fantastic, the best browser during decades and a great help for web devs like me; is slowly going down and down, and near to be the worse of all, nowadays. I do not use-it any more for my work, and near to un-install-it for good !
Well, my site will continue to show an infamous warning against FF, this kind of warning we used against IE( up to 6) during decades !
I suspect bug 572520 email@example.com: >I do not know what i have to do in order some dev take this ugly bug in >consideration. A non critical bug like this one needs usually weeks/months to get fixed. What could help is a minimized testcase.
Status: UNCONFIRMED → NEW
Component: Untriaged → ImageLib
Ever confirmed: true
Product: Firefox → Core
QA Contact: untriaged → imagelib
> A non critical bug like this one needs usually weeks/months to get fixed. It really depends. Moving it to the right place, as you did, is a good start.... Reporter, what would help the most here is what Joe said: a site version that uses unminified JS. Also, anything you or someone else can do to reduce the testcase as much as possible would be good. My guess is that the page is doing measurement of the image before the size of the new image is available, but it's hard to tell with all the indirection in the script.
Emails send as requested. Isuppose too a problem with the style width:auto and heigh:auto. Strange, anyway, as the first images are correctly set. Will try to find some time to build a page with the script unminified and less images to help bebuging.
Well, as far i'm concerned, i will consider F.F. as DEAD. I un-suscribe from here and un-install. I'm furious and disappointed. Reasons ? New version each week, (nobody making tests before to publish ?)sometimes each day, and many of them brake something, making some extensions or plugins obsolete, just boring... Heavy, complicated and slow, comparing to others, IE included. The worse development team. Hundreds of uncorrected bugs for months, and, as you can see here, nobody *really* care ! it's affraying. By by Mozilla, continue to throw the baby out with the bathwater, if you like, but without us (we are legion and sad) !
The problem here is that the work needed to figure out what's going on is large. Think days of effort just to figure out which parts of the site are responsible. It'll happen, but there are other higher-priority things that need to be done (in my case, caring for a sick child, say). Are you OK with me attaching the unminified script you sent me here so someone else can try to get somewhere with minimizing the testcase if you don't have time to do it yourself?
It is pretty complicated to un-minimize the scripts ( in production). The site use both Mootools and Jquerry, and there is a lot of dynamic scripts to avoid JS conflicts, minimize both JS and css on the fly (and cache them). I had tried to make for you a static version, but it does not work, will try to figure out where is the problem. The script itself is located here: http://www.street-photo.fr/fr/modules/mod_rokslideshow/tmpl/rockslideshow.js In the minimized version, search for /* FILE# 6 Take care of your sun (indeed more important), and thank-you for your care of this problem. If, one day this bug is solved, please, can somebody mail-me in order i can remove this infamous F.F. warning from my code ? Best regards, Christophe
I'm not sure I follow comment 16... That code is setting the width and height styles on the <img> tag, right? Before it was setting them to the width/height properties of the image and this failed? And now it's setting it to the name and id? Are you setting the name and id to the image dimensions in your HTML or something? In any case, img.width and img.height depend on two things: the image's styles and whether the image metadata is available. Given that this bug appeared when bug 572520 was fixed, it sounds like your site is changing an image src and then reading width and height synchronously. Per spec, the width and height should become available asynchronously... Joe, I wonder whether we need to fix that for the case of "preloaded" images (and get the spec changed). I don't think any other browser has that behavior....
And by the way, I really appreciate your figuring out which exact line of code was triggering the problem! That was _very_ useful information.
Hmm. I wonder whether the issue is that with async notifications for precached images we're not switching from mCurrentRequest to mPendingRequest until much later. Let me see if I can write up a testcase here.
I sent http://lists.w3.org/Archives/Public/public-html/2012Mar/0496.html about the spec being broken here. I'm going to do a try build with this patch. Would you be willing to test whether it fixes the original problem on your site? Basically, switch the site to the old behavior for a few minutes, test with the test build, then switch it back.
Assignee: nobody → bzbarsky
Priority: -- → P2
Whiteboard: [need review]
Comment on attachment 606457 [details] [diff] [review] Update the width/height of an image synchronously when src is set to something that was preloaded. Review of attachment 606457 [details] [diff] [review]: ----------------------------------------------------------------- ::: content/base/src/nsImageLoadingContent.cpp @@ +807,5 @@ > + pusher.PushNull(); > + > + // This is a terrible hack to make nsImageFrame pick up the fact that > + // it needs to reflow.... > + LOOP_OVER_OBSERVERS(OnStopDecode(req, NS_OK, nsnull)); What's going to happen when the real OnStopDecode comes through from the image?
I went trawling through Try. Here are the results: https://tbpl.mozilla.org/?tree=Try&rev=7f8434f967df And here is the build, presuming you're on Windows: ftp://firstname.lastname@example.org/try-win32/firefox-14.0a1.en-US.win32.installer.exe
Yep. You can get all the builds for that try push from https://email@example.com/
> What's going to happen when the real OnStopDecode comes through from the image? It'll get called again. nsImageFrame happens to ignore OnStopDecode for the current request, and it would be the current request at that point, so it would work. The other option is to add an explicit API to notify the image frame in particular here. I could do that, I guess..
Thanks for confirming that! I don't think we need to test against the site anymore if the build you tried fixes the problem; that just indicates that we diagnosed it correctly. And thank you again for finding the relevant spot in your code. That was very very helpful.
Did i have to set the status of this bug to "resolved" , or did Boris Zbarsky (thanks again) have to do-it itself ? I don't know the habits and rules over there ;-)
I'll mark the bug resolved once a patch actually lands. That hasn't happened yet.
Comment on attachment 606457 [details] [diff] [review] Update the width/height of an image synchronously when src is set to something that was preloaded. > > /** >+ * Switch our pending request to be our current request. >+ * mPendingRequest must be non-null! >+ */ >+ void SwitchToPendingRequest(); This name confused me at first, because I thought it meant that we were somehow switching to mPendingRequest rather than the value contained therein. Maybe something like MovePendingToCurrent() or something? It's also possible that my confusion was unjustified, so if you think it's a good name I'm fine with keeping it. (In reply to Boris Zbarsky (:bz) from comment #26) > The other option is to add an explicit API to notify the image frame in > particular here. I could do that, I guess.. Please do that - it will make things saner when I refactor this whole API. Looks good otherwise. r=bholley with the above.
Attachment #606457 - Flags: review?(bobbyholley+bmo) → review+
(In reply to Bobby Holley (:bholley) from comment #32) > Please do that - it will make things saner when I refactor this whole API. Also, I'd very much like if we could call that API function _after_ making the request current. The way it works currently depends on the async-ness of reflows, which is nasty.
> Also, I'd very much like if we could call that API function _after_ making the request > current. I'll see what I can do, but right now we use the "request is pending" bit to detect that we have to recompute the intrinsic size... > The way it works currently depends on the async-ness of reflows, which is nasty. We depend on that all over. It's not an unreasonable thing to depend on.
Attachment #606457 - Attachment is obsolete: true
Attachment #607168 - Flags: review?(bobbyholley+bmo) → review+
Whiteboard: [need review]
Target Milestone: --- → mozilla14
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.