Closed Bug 92248 Opened 23 years ago Closed 23 years ago

Flickering images on mouseover

Categories

(Core :: Graphics: ImageLib, defect, P2)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.6

People

(Reporter: markushuebner, Assigned: pavlov)

References

(
URL
)

Details

(4 keywords, Whiteboard: [PDT-], [ETA 10/3] has r= and sr=. needs a= branch.)

Attachments

(2 files, 4 obsolete files)

ethereal tcpdump
12.96 KB, application/octet-stream
Details
Working patch against the 0.9.4 branch
37.63 KB, patch
mscott
: review+
attinasi
: superreview+
Details | Diff | Splinter Review 
Just go to
http://www.payplus.at/footer.asp
and move the mouse over on of the pics ... they are flickering
Another testcase at
http://www.world-direct.com/mozilla/footer.htm
There everything looks fine.
Keywords: mozilla0.9.4, regression
using build 2001072403

the page looks fine in MSIE, NS4X and Opera.

This is a standard JavaScript feature used virtually on every website.
So this should be looked at quite soon.
Severity: normal → major
Keywords: 4xp
Any ideas jst ?
Component: Browser-General → DOM Level 0
reassigning
Assignee: asa → jst
QA Contact: doronr → desale
*looks* like a caching problem.. see bug 17126
Over to imagelib.
Assignee: jst → pavlov
Component: DOM Level 0 → ImageLib
QA Contact: desale → tpreston
*** Bug 93368 has been marked as a duplicate of this bug. ***
Taken from my dupe of this bug (93368) - this page is an extreme example of this
bug:
New testcase:
http://orange.net.au

on linux 0.9.3
OS should be changed to all.


Changing to "All".
Adding "nsCatFood" since this is very annoying on web-sites.
Keywords: nsCatFood
Discovered that the flickering testcase has the used JavaScript function in an 
external file and the one working has the function inside the HTML file.
Can this cause this effect?!
OS: Windows 2000 → All
Hardware: PC → All
the bug on the homepage of Sapient - one of the biggest web agencies in the 
world - http://www.sapient.com  move the mouse over one of the pictures on the 
right hand side
Severity: major → critical
Go to http://www.world-direct.com/miss-tirol/index.asp?ueber
and move the mouse over the left top items.
It's really terrible!

This is not only gifs.
The URL http://www.jvp.or.at/steyr/ has pngs (left frame) and shows this as well.

Changing summary for that.
Summary: Flickering GIFs on mouseover → Flickering images on mouseover
what  the reporter means is, when you onmouseover over the images, the image is
replaced with box (temp placeholder) while it waits for the new image to be
downloaded. Other browsers keep the old image shown until the new one has been
fully fetched. Not sure if this is a Imagelib issue or a DOM issue...
Severity: critical → major
No, it seems not only to be the temp placeholder. I experienced in my case that
all the images were loaded again and again via the network when mousing over.
Shouldn't they be in the cache after the first time (I have it enabled)?
aceepting for 0.9.5.. P2
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.5
http://www.payplus.at/footer.asp - yes, I see network activity when mousing over
them, seems that they are not cached
can this somehow be fixed?!
It's no good reputation to have such an obvious bug in a release at this time.

Is this the same bug that is causing my forward, back, reload, and stop buttons
in the chrome to flicker when I mouseover them?
think so!
The toolbar buttons flicker if you have cache set to 0 or off. If you turn it 
on, it will work. That's another bug, in bugzilla, already filed though.
Bug occuring on major sites.
Updating keywords.
Keywords: nsbeta1, nsbranch, testcase, top100
at http://www.payplus.at/footer.asp a GET is issued for each mouseover and
another for each mouseout. I have cache enabled and set to compare "Automatically".

For each GET there's also a cookie to WEBTRENDS exchanged.

I see the exact same behaviour in Netscape 4.77, it's just performing the same
task a little faster, and with noticable disk rattling.

If i should guess, i would have thought this was by design, created as a
hit-generator?

Attaching dump from ethereal 0.8.18 (ethereal/tcpdump format)
Attached file ethereal tcpdump — 

    
    

    
  
made a testcase at http://home.c2i.net/dark/test/92248.html

The GET request for images are still triggered on each mouseover.
But the cookie request doesn't happen.
On a P3/500 the images now load instantly, even if new GET's are issues all the
time. So the slowness seems to be in the cookie responses from server,
preventing images to load before the entire cookie content is aboard.

I tested other URL's mentioned here, and i do not see this bug at any other
sites than those belonging to reporter:
http://www.payplus.at/footper.asp and
http://www.world-direct.com/miss-tirol/index.asp?ueber

There is no extranous GET's and no visible lag at
http://www.sapient.com which is mentioned somewhere in this bug.

    
    

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

    
    

    
  
R.K.Aa
just4info ... see also the comments in bug 99051.
And using build 2001091003 on win2k still see the flickering on www.sapient.com



    
    

    
  
I believe there are two completely different issues here.
The original bug is a networking cookie performance issue as far as i can tell,
where mozilla doesn't handle a "cookie flood" very well.
That bug i do see, but try the testcase i made, same images and scripts without
cookies.

The mousein/out slowness at sapient.com i do not see on linux, and a tcpdump
shows no network traffic when continuing to mouse over the images.


    
  
Keywords: mozilla0.9.4, 
          
            nsbranch → mozilla0.9.5, 
          
            nsbranch+

    
    

    
  
also seen on Bang & Olufsen website
direct link - http://www.bang-olufsen.com/top7.php
just move over "Family Beoadvisor News ..."



    
    

    
  
Adding correctness Status Whiteboard, correct/expected behavior does not occur.
Whiteboard: [correctness]

    
    

    
  
There's a theory that this is cookie related.  Has anyone done follow up on
that?  With no patch available, this has almost missed the next release already.
 Please update the bug with your progress.  It's almost too late for this one,
but I'd like to hear where you're at first...
Whiteboard: [correctness] → [correctness]  need info

    
    

    
  
Pavlov is working on it! We really need to get this one into the next release 
since this already caused major inconveniences/usability problems in 0.9.4

Pavlov - what's the current status?

    
    

    
  
When did this regress?

    
    

    
  
terri - can you check in Netscape 6.1 to see if this problem occurred in that
version?  Thanks.

    
    

    
  
I see that this bug doesn't happen in some of the links mentioned any more, for
example, with today's build, Sapient's home page doesn't have any problem. Using
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20010924 Netscape6/6.2 

Pavlov, can you give us status on it?

    
    

    
  
Just tried all testcases - the bug is still there.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4+) Gecko/20010925

On Sapient.com the images on the right hand side flicker as well as the red 
ones (right from the sapient logo) [what we do | industries ...].

Testing with Netscape 6.1 the sapient site works and the flickering on the 
other ones is much less. So regression must be happened somewhere after it.

    
    

    
  
Can you try and get us an ETA by the end of today?
Summary: Flickering images on mouseover → Flickering images on mouseover, [PDT], [ETA ?]

    
  
Summary: Flickering images on mouseover, [PDT], [ETA ?] → Flickering images on mouseover, [PDT], [ETA 9/28]

    
  
Summary: Flickering images on mouseover, [PDT], [ETA 9/28] → Flickering images on mouseover
Whiteboard: [correctness]  need info → [PDT], [ETA 9/28]

    
    

    
  

      
      
      
      

        Attached patch
          
          
        First pass (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 51012 [details] [diff] [review]
First pass

here's the first pass patch for this bug.
it fixes flickering, but seems to slow down mouseovers.
images don't always load :)

        Attachment #51012 -
        Flags: needs-work+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch that mostly works (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
ok, this patch seems to be slightly better.  images no longer disapear and 
things don't seem to be much slower..

things that are probably still broken:
changing to/from animated images
changing to/from different sized images


    
  

        Attachment #51012 -
        Attachment is obsolete: true

    
    

    
  
> changing to/from animated images

Isn't this part bug 17126?


    
    

    
  
sigh.  pushing ETA off to 10/1.  This is requiring more changes that I had
anticipated.
Whiteboard: [PDT], [ETA 9/28] → [PDT], [ETA 10/1]

    
  
Whiteboard: [PDT], [ETA 10/1] → [PDT], [ETA 10/3]

    
    

    
  
what are the chances this will make the trunk?

    
  

        Attachment #51021 -
        Attachment is obsolete: true

    
    

    
  
Ok, what this ptach does:
Basically, the image frame now stores an array of 3 image requests so that it 
can easily swap one out for another.  This allows the code to kick off 3 loads 
(1st being the main image.. what will be displayed, 2nd the lowsrc image, and 
3rd being any image load that results from a src attribute changed).
Previously, the code would remove the main image when it wanted to load a new 
image for an attribute change.
So what now happens is the main image will remain in place until the new image 
is complete, at which point they will be swapped out.  this will either result 
in a reflow or invalidate of the frame depending on if the size of the frame is 
fixed or not.

    
    

    
  
- In imgLoader.cpp:

+  if (_retval) {
+    ...

AFAIK this is not XPCOM-cool, I'd suggest you require callers to pass in a valid
out pointer, i.e. a dummy even if they don't care about the return value from
this method. That would be much cleaner IMO.

- In nsImageFrame::OnStartContainer():

+  int whichLoad = GetImageLoad(aRequest);
+  struct ImageLoad *load= &mLoads[whichLoad];

GetImageLoad() will return -1 if aRequest is not one of the 3 loads in the image
frame, either check for -1, or make GetImageLoad() always return a valid number...

- Missing == in:

+  if (whichLoad -1) return NS_ERROR_FAILURE;

With that fixed, r/sr=jst

    
    

    
  
In nsImageFrame.cpp,

+    // XXX this is wrong.  don't let me check this in.
+    mLoads[0].mTransform.TransformCoord(&r.x, &r.y, &r.width, &r.height);

?

    
    

    
  
ok, fixed jst's comment and removed the line stephend pointed out.. the code 
around the comment I fixed just prior to the patch.

    
    

    
  
Comment on attachment 51972 [details] [diff] [review]
Patch to solve problem (diffed against 0.9.4 branch)

r=bryner (and adding jst's sr=)

        Attachment #51972 -
        Flags: superreview+

        Attachment #51972 -
        Flags: review+

    
  
Keywords: patch
Whiteboard: [PDT], [ETA 10/3] → [PDT], [ETA 10/3] has r= and sr=.  needs a= for trunk and branch.

    
    

    
  
Is this the same as bug 86071?

    
    

    
  
can we talk about this one in the PDT today?

    
  
Blocks: 86071

    
    

    
  
let's let it sit on the trunk for a day, and land this over the weekend on the
branch (if there are no problems).
Whiteboard: [PDT], [ETA 10/3] has r= and sr=.  needs a= for trunk and branch. → [PDT+], [ETA 10/3] has r= and sr=.  needs a= for trunk and branch.

    
    

    
  
Good Grief! This is _so_ not a stop-ship bug. Nor is its dependent. Furthermore,
now is a horrible time to bake anything on the trunk: we're trying to shut down
mozilla-0.9.5 so we can re-open the trunk next week and get on with life.

If you really want this fix, then get a shippable candidate for NS6.2 and put
this in as a ``limbo'' checkin afterwards.

    
    

    
  
checked in on trunk.
Keywords: vtrunk
Whiteboard: [PDT+], [ETA 10/3] has r= and sr=.  needs a= for trunk and branch. → [PDT+], [ETA 10/3] has r= and sr=.  needs a= branch.

    
    

    
  
Did this checkin just stop all non-background images
from loading?  (Linux, CVS-HEAD at time of writing.)

    
    

    
  
If you have an opt build, you need to run regxpcom.

    
    

    
  
Perfect -- thank you.


    
    

    
  
could this be causing bug 103477?

    
    

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

    
    

    
  
I reopened bug 103558 as it seems it has another, related feature:
The onMouseOver graphics are now cached *every time* they are used, even with
once-per-session cache setting. 

    
    

    
  
It is a little late for this one = PDT-

:-(
Whiteboard: [PDT+], [ETA 10/3] has r= and sr=.  needs a= branch. → [PDT-], [ETA 10/3] has r= and sr=.  needs a= branch.

    
    

    
  
This is probably the most obvious bug of mozilla right now, as it is seen on 
nearly every website (quite all have some kind of mouseover effect).
If somehow this can make it, this would be a major step forward concerning 
convenience/usability.


    
    

    
  
we would have liked to take it, but it is too risky to take at time.

    
  
Blocks: 104166

    
    

    
  
Looks to me like this has been fixed (since Stuart's check-in on October 5).

    
    

    
  
[as outlined in my mail pavlov]
concerning the current fix for this:
take for example
http://studio.adobe.com/resources/main.html
in the top navigation you must leave the cursor for at
least a second over the image to see the mouse-over effect.
that's unfortunately way to long.
it also happens that there are several items highlighted.

what I discovered ... everything on site A is real slow ...
then going to site B ... surfing a bit around ... going back
to site A and now everything is completely fine! :)


    
    

    
  
On the branch 094, the mouseovers appear ok, but if the user presses reload, the
user will see the white box on mouseover. 

    
    

    
  
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6

    
  
Blocks: 61480

    
    

    
  
If this helps... the flicker I have seen is on the sidebar mouseovers using at
24 bit colors.   At 32 bit color depths, there is no flicker and mouseovers
seeem to work correctly... at least for me...


    
    

    
  
Wow - when I look at today's  0.9.4 branch with modern skin on mac - 
when I rollover the sidebar tabs, they flicker like mad.  Each time I mouse 
over them the image is replaced by a blank image for a moment then the 
image loads - for each tab!   This seems to be quite a visible problem and 
still exists on the branch.

   



    
    

    
  
seems to me that the original bug that was reported for this bug # was fixed

with build 2001101603 win32 all these wfm:

http://www.sapient.com/default.htm
http://www.world-direct.com/miss-tirol/index.asp?ueber
http://www.jvp.or.at/steyr/
http://home.c2i.net/dark/test/92248.html
http://www.bang-olufsen.com/top7.php
http://studio.adobe.com/resources/main.html

As for the sidebar tabs, would that be considered a different bug?

    
    

    
  
basic: this is fixed on the trunk, but it is not fixed in 0.9.4 branch, and I
(and it seems also others) still think it should be included in NS6.2 release
because it would piss some/many users off to see such an ugly thing...

andreww: I also saw the bug occurring on fast mouseovers on toolbar buttons in
modern, when it still wasn't fixed on the trunk. Now that it is fixed,
everything looks smooth again. And the patch does work really good, as the trunk
showed...

    
    

    
  
why is this a mozilla0.9.6 ? it is fixed on the trunk right?

    
    

    
  
To ship NS6.2 with this bug will cause some major usability problems and 
inconveniences among users and web-developers.
Anway, it's important to return to the "normal (speedy) onmouseover behaviour" 
as it's seen with NS4.X, MSIE, etc. Just see my comment from 2001-10-11.

    
  
Blocks: 107066

    
  
Keywords: nsbranch+

    
    

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

    
    

    
  
i'm marking this fixed.  it is clear to me that this isn't wanted on the 0.9.4 
branch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

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

    
    

    
  
Think this one should not have status "fixed" since the used behaviour isn't 
restored. Please see my comments about the long time delay causing major 
usability problems - since some users won't see the onmouseover effect at all 
if it takes that long.

Pavlov, do you know what causes this delay and when this will be fixed?

    
    

    
  
I agree that it should not be marked as 'fixed'. As an example, go to The
Register (http://www.theregister.co.uk/) and mouse over the menu in the top
right corner. The menu items are supposed to flash black when the mouse is over
them (try it in any other, non gecko-based browser), but in Moz they react very
slowly. This gives an impression of a slow browser... While you and I know it
isn't, many people won't know this and judge Mozilla on this behaviour...

    
    

    
  
Reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Markus: please file a new bug for the delay, the flicker problem is fixed. Oh
and mention the new bug # here too ;-)
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
The delay you are seeing is probably bug 93461

    
    

    
  
Filed a new bug about the delay problem - bug 108161

    
    

    
  
Added edt0.9.4
(other url example - bugscape 5335)
Keywords: edt0.9.4

    
    

    
  
asa, can you request that the 0.9.6 rel notes include some text suggesting
testing around this?

    
    

    
  
Judson: For the Release Notes, you may wish to write up a draft-request in a
comment for bug 104896.

    
    

    
  
Another example: http://www.thewb.com (and its sub pages).

    
    

    
  
at http://www.thewb.com it here (Linux 2001103021, P3/500) only happens the
first time. Once the new picture is loaded, it seems to be cached and pretty fast.
So the problem here is mainly loading the pictures when the rest of the page is
loaded. A perfect solution would be to load it just after the rest of the page
is loaded, so users with slow connections see the visible page loading as fast
as possible but still don't see the delay when moving the mouse over the menu
(given that he does it after the page is fully loaded).



    
    

    
  
at http://www.thewb.com it here (Linux 2001103021, P3/500) only happens the
first time. Once the new picture is loaded, it seems to be cached and pretty fast.
So the problem here is mainly loading the pictures when the rest of the page is
loaded. A perfect solution would be to load it just after the rest of the page
is loaded, so users with slow connections see the visible page loading as fast
as possible but still don't see the delay when moving the mouse over the menu
(given that he does it after the page is fully loaded).
Anyway, I guess this is a different bug. Was it already filed? Has someone a bug
number?

    
    

    
  
Another important site, which happens even after the first time the images have
been rolled over: http://www.sony.com/

    
    

    
  
On my linux build 2001110712 the images do NOT flicker anymore. The slow
mouse-over effect is still there, but the flickering seems to be gone. Here,
that is...

    
    

    
  
Also seeing the "first time flicker" on www.sony.com using build 2001110803 
(win2k)

    
    

    
  
How about this--mouseover left nav links. Look like the same bug?
http://commerce.www.ibm.com/content/home/shop_ShopIBM/en_US/athome_promotions.html

    
    

    
  
Can't see any images on the left navigation.
Just a "hoover-effect" working fine so far.
build 2001111203

    
    

    
  
Terri, To plus (+) this for 094 we need to have the bugg verified on the trunk.

    
    

    
  
Verified fixed win XP 2001112903, linux build 2001112908 and mac build 2001112806
Status: RESOLVED → VERIFIED

    
    

    
  
EDT - Pav you can go ahead and put this on the branch.  

Terri - were you able to find any regressions on any 0.9.6 bugs?

    
    

    
  
Not that I know of, let me know if you have particular bugs you think have regressed

    
    

    
  
sigh.  you ask this *the day* after i remove this from my branch build.  I'll
see what I can do.. there is going to have to be a lot of work to get this
merged back to the branch now... :(

    
    

    
  

      
      
      
      

        Attached patch
          
          
        new patch against branch (obsolete)
        — 
          — Splinter Review
      

    


  
here is a new patch against the branch.. its missing
modules/libpr0n/public/ImageErrors.h so copy it from the trunk if you want to
build with this.

for some reason, images arn't painting when they need to be exposed... i'm
trying to figure this out...

        Attachment #51972 -
        Attachment is obsolete: true

    
    

    
  


  
Here is a working patch.  The bug was an error I had made when merging:
I had:
	     inner.IntersectRect(inner, aDirtyRect);
+	     nsPoint p(inner.x, inner.y);
instead of 
+	     nsPoint p(inner.x, inner.y);
	     inner.IntersectRect(inner, aDirtyRect);

so the point was wrong :-)

        Attachment #60604 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 60718 [details] [diff] [review]
Working patch against the 0.9.4 branch

sr=attinasi

        Attachment #60718 -
        Flags: superreview+

    
    

    
  
please checkin to 0.9.4 branch. once there, add "fixed0.9.4" to the keyword
field. thanks for all the sweat for back port; we owe you.
Keywords: edt0.9.4 → edt0.9.4+

    
    

    
  
Comment on attachment 60718 [details] [diff] [review]
Working patch against the 0.9.4 branch

r=mscott

        Attachment #60718 -
        Flags: review+

    
  
Keywords: fixed0.9.4

    
    

    
  
Another site: http://kraft.promotions.com/holidaywishes/
(Marked it topembed as it's very prolific; even though it's cosmetic it really
degrades the expected user experience.)
Keywords: topembed

    
  
Keywords: nsbranch

    
    

    
  
A couple more examples (partners):
http://www.videoprofessor.com/ (left nav)
http://www.cw.com (nav buttons in middle of page)

    
    

    
  
Also occurs on Ofoto.com (click Quick Tour then mouseover tabs)

    
    

    
  
verified0.9.4 win2k
Keywords: verified0.9.4

    
  
Keywords: fixed0.9.4

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: