Closed Bug 460792 Opened 16 years ago Closed 8 years ago

Image double loading in quirk mode

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jeff-watts, Unassigned, NeedInfo)

References

Details

(Keywords: regression, testcase)

Attachments

(1 file)

Simple html and images to reproduce problem
6.18 KB, application/x-zip-compressed
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

When using quirk mode we find that image load appears to take two steps with the first step actually including the image. While this looks like a minor issue when seen in a simple example, in our more complex application its more obvious with the large number of images displayed on our pages reloading.
If loose mode is set, the problem goes away.

Reproducible: Always

Steps to Reproduce:
1. Using the sample provided, clear cache and restart firefox 3.0.3
2. Click on the load button and observe the ripple as the images are loaded


Actual Results:  
The images load in sequence with a ripple effect. 

Expected Results:  
Image load should not have the ripple effect, regardless of browser mode.

To repeat the browser cache must be cleared and browser restarted. Sometimes it takes a couple of clearings and/or browsing other side to repeat.

If strict mode is turned off (add following to sample file: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">), the problem goes away.
use sample to reproduce.
Do you mean that they zoom out?
I mean: they seem to start too large initially.
It happens pretty fast in the test case so its hard to pin down exactly what is happening. But yes, they see a bit larger initially. Then squeeze to the left a bit as they complete rendering.
In the big application you can see that some kind of temporary image is loaded first followed by the final image. But it happens slower so its easier to see. 
So, I am assuming the test case behaviour and what I see are one and the same issue despite be unable to clearly see the first image in the test case scenario.
Confirmed on Windows XP, latest trunk. 
Works: 2007011217
Fails: 2007011220
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2007-01-12+16%3A00&maxdate=2007-01-12+21%3A00
Bug 365173 or Bug 366207 or even Bug 363329 ?
Blocks: 365173
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
Keywords: regression, testcase
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
Flags: blocking1.9.1?
When you added the dependency only to bug 365173, did you have evidence that it was that one, or were you guessing?
Flags: blocking1.9.1? → wanted1.9.1+
Firefox: 50.0a1, Build ID  20160704030211
User Agent:  Mozilla/5.0 (Windows NT 5.1; rv:50.0) Gecko/20100101 Firefox/50

I have tested this issue on the latest Firefox (47.0.1) release and latest Nightly (50.0a1) build, but I could not reproduce it. For testing this I have used the provided test case from comment 1. After pressing the "load" button, the image is completely loaded without any ripple effect. 

Jeff, is this still reproducible on your end ? If yes, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results?
Flags: needinfo?(jeff-watts)
Considering the fact that I cannot reproduce this and the fact that the reporter did not answered to my request until now, I will mark this as Resolved-Worksforme.

If anyone can still reproduce it, feel free to reopen the issue and provide more information.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: