Closed Bug 17322 Opened 26 years ago Closed 24 years ago

Preference of which is preferred - fast layout/stable layout

Categories

(Core :: Layout, defect, P3)

x86
Other
defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: CodeMachine, Assigned: kmcclusk)

References

Details

It would be nice if a user could distinguish between preferring fast layout (render data as soon as available) or stable layout (don't render anything until you're sure it will stay that way). Things that can lead to a rendering change include: o incremental flowing of tables, etc. (see bug #854) o images not yet loaded (see bug #1994) o primary stylesheet not yet loaded (see bug #17309)
This could be backed up with a timeout, see in particular bug #17309.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WONTFIX
We need to improve the load time. What you see today is just step one in the process. There's a lot of tuning we need to do
Actually, I created this with no regard to the current state of Mozilla. I haven't even seen the effects of bug #854 yet. No matter how much you optimise Mozilla, you're still going to have network effects, and this will still be an issue.
How about a preferences setting for "Re-render page at most every [N] seconds"? I.e. after each layout/redraw, wait for at least N seconds (or until all streams have finished loading) before doing it again in response to a network event. The wait would also be incurred at the beginning of the load.
Eeep, that idea is already covered in depth ... see bug #17325. Sorry.
I really want to avoid adding preferences for this kind of thing if it can at all be helped. We've done this in the past and it has made the browser UI way too complicated and we've ended up eliminating many of the preferences
No such thing as too many preferences. The lack of prefs in the 4.X series GUI made me spend a couple weekends writing an app to mimic the Netscape prefs dialog, but include all known working prefs. Hopefully with Mozilla we will get prefs documentation that actually is correct.
Status: RESOLVED → VERIFIED
Based on troy's comments, marking as verified wont fix.
To Fix the preferances problem, allow a 'show full preferaces' flag to be set in the preferances box, much like ICQ's Simple and Advanced mode. Then just add all additional preferances into advanced mode, the default mode being simple
*** Bug 34018 has been marked as a duplicate of this bug. ***
Reopening. Too many people want this. If you don't want to clutter the UI, make it a back-end only pref. There are plenty of these around. We can later put it into the UI under bug #17199 or some such similar thing.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
What about displaying *something* in stable layout mode, if data is available (text) Then ask the user whether to update it when you're sure that the layout will stay that way Maybe the dialog would open only if it has been a significant amount of time since first rendering (so the user could read the text)
Reassigning to kmcclusk.
Assignee: troy → kmcclusk
Status: REOPENED → NEW
Target Milestone: --- → mozilla0.9.1
This can already be controlled for the most part using the content.notify.interval pref: If you set this value to: user_pref("content.notify.interval", 2000000); Then layout/display will not happen until most/all of the page has been loaded. If you leave it at its default or make it smaller: user_pref("content.notify.interval", 125000); then layout/display will occur almost immediately when content arrives. The default which I just checked in a change for is: user_pref("content.notify.interval", 250000); Granted, this is not as precise as the solutions that have been suggested in this bug but it does accomplish the goal of letting the user "distinguish between preferring fast layout (render data as soon as available) or stable layout."
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → Future
Marking WONTFIX
Status: ASSIGNED → RESOLVED
Closed: 26 years ago24 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.