Comment 204 for bug 125970
Revision history for this message
|
|
#204 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
513534c
demo site
(Get the code!)
> it looks to me as if you're trying to convince
> everyone that there isn't any bug.
I do not see a bug. I can not reproduce the problem when using a trunk build on windows. I can not reproduce the problem when trying all of the mentioned URLs so far, including this bug's provided URL http://
and attachment #139911 . Now, if the bug is still happening on the trunk, then provide a testcase relevant and relative to this bug. Do you understand?
I am trying to convince you that several of the so-called URLs, testcases included in this bug were
- 404 not found
- redirected to nowhere
- abusing or depending on Flash
- abusing or depending on javascript
- have huge amount of coding errors, are examples of over-excessive formating, over-excessive coding, declaring, over-constrained layout,
- etc..
and that none of this serve the purpose of demontrating or reproducing or isolating a bug or faulty behavior or weak performance. If this bug still occurs, then at least a large minority of us should notice, measure something significant when trying attachment attachment #139911 or this bug's provided URL.
> I do think there's is something with this
> position:fixed
Fine! Then proceed accordingly with
What is a Simplified Test Case, and How Do I Make One?
http://
How to Really, Really Help Developers on Bugs -- Minimal Testcases
http://
There are such things as the capability to reproduce a bug under controlled conditions, where we can compare data, examine testcases, use and compare (before fix and after fix) performance profiles, etc... Otherwise we shouldn't confirm a bug.
> I wasn't comparing smoothscroll.
Why do people in this bug keep mentioning smooth scroll then? Why can't you provide smooth scroll related data to respective bugs like bug 202718 (Windows), bug 424308 (Mac), bug 409456 (Linux)?
> Here are the results again, with smoothscroll off:
> FF2: between 3 and 5 seconds, redrawing maybe 4 or 5 times a second
> FF3: between 13 and 15 seconds, redraw once a second
> that's 4 to 5 times slower.
Which test case are you referring to? What's your overall system configuration for getting those data? I can not reproduce anything close to your data with this bug's provided URL http://
and attachment #139911.
> I've posted an attachment already a few weeks ago, cleaned up from all the
> images only but not css. I know I should have created a simple file with a
> fixed div and some text... I did read the 'howto' file a bug and do tests,
> etc...
>
> But in my case it's a bit complex.
It is **NOT** just a bit complex. It's an 85 Kilo-byte HTML file (7598 lines of code, 86193 bytes!) with several linked (external and imported) stylesheets and several linked external javascript files that we can not see or examine with your RAR compressed file because your very long HTML file uses relative addressing, not absolute addressing. And I'm not even mentioning inline style, inline javascript code, invalid markup code, for populating dynamically "n" tables and table cells, etc..:
<link href="screen.css" rel="stylesheet" type="text/css" />
<style type="text/css" >
@import url("inc/
</style>
<script src="combine.
<title>Planning - last mod: Sun, 13 Apr 2008 12:18:39 GMT</title></head>
<body>
<script type="text/
<script type="text/
<script type="text/
<style type="text/css" >
@import url("inc/
</style>
<script type="text/
function client_
dojo.xhrGet( {
url: "####="+id_client,
handleAs: "text",
timeout: 5000,
load: function(response, ioArgs) {
return response;
},
error: function(response, ioArgs) {
return response;
}
});
}
</script>
<script type="text/
Calendar.setup(
{
inputField : "startInputTime", // ID of the input field
ifFormat : "%d-%m-%Y", // the date format
button : "startInputTime" // ID of the button
}
);
Calendar.setup(
{
inputField : "stopInputTime", // ID of the input field
ifFormat : "%d-%m-%Y", // the date format
button : "stopInputTime" // ID of the button
}
);
Calendar.setup(
{
inputField : "startEmptyInpu
ifFormat : "%d-%m-%Y", // the date format
button : "startEmptyInpu
}
);
Calendar.setup(
{
inputField : "stopEmptyInput
ifFormat : "%d-%m-%Y", // the date format
button : "stopEmptyInput
}
);
</script>
> So please bear with me and maybe advise me
> on how to proceed with this case.
I have already:
What is a Simplified Test Case, and How Do I Make One?
http://
How to Really, Really Help Developers on Bugs -- Minimal Testcases
http://
> In this case:
> I have a png in the background, and a png in the fixed div, and a hole lot of
> tables, lot of stuff styled... All together it's slow. See results above.
> If I get rid of the fixed div. It's back to normal, it's not slowed down. This
> tells me I'm in the correct bug, and I'm not posting in the wrong place.
> BUT with the fixed div:
> If I get rid of the png backgrounds and keep the fixed div, it's still slow but
> a lot better. And when I get rid of all the css styles, then it's back to a
> normal speed. Speed difference slightly visible.
> Concludion:
> - Clean of images and css, difference slightly visible.
Those images are relatively linked. So we can not examine or test them. Non-optimized images is not rare on the web. Linked external stylesheets with relative links, not absolute links; same thing with javascript. Your testcase is for sure not a good testcase it does not - I REPEAT - does NOT allow us to examine what you have in those external files linked into your 85KB HTML webpage.
> - Alltogether, css, images, etc... Big difference between the version that has
> the fixed div and the one that hasn't.
This bug is about positioned fixed elements. This bug is not about images with background-
This bug is supposed to be occuring even with javascript disabled. This bug is about positioned fixed elements. This bug is not about populating dozens of tables and hundreds of table cells dynamically.
> Now I'm only speculating on how this is possible...
The difference between a good testcase and a bad one is that a good testcase reduces questions, it removes doubts, it reduces/eliminates speculation, it's more targeted, it clarifies the target, it isolates the real issue, it's useful to verify that the bug has been fixed, etc.
Your attachment 315511 does none of that. First off, we can not even examine the images, the imported and external linked stylesheets, the javascript external files, etc.. because the linkage you use in that attachment 315511 is relative, not absolute. On top of that, once uncompressed, the attachment 315511 becomes a 85KB file with 7598 lines of code!!
> So no I will not post a testcase like attachment #139911 [details], because it doesn't
> represent what I get.
attachment #139911 represents accurately and reliably what this bug's summary is about. If you notice/measure no significant loss of performance or speed or time duration on the trunk, then I say this bug has been FIXED already (bug 203439 has been FIXED, you know) and should be resolved as WORKSFORME. Do you understand?