You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What I'm experiencing
I have an asset that needs to be generated each time it's loaded & it can take a while to finish loading in some circumstances. As such, sometimes the print operation is triggered before it's done loading & the asset is not included when it should be whereas some other times everything's all ready to print and the user needs to wait an unnecessarily long time before the print event is triggered.
My proposed solution
I'd love to see something like having printDelay support a value of auto (or onload or whatever you want to name it) which then watches the iframe that printThis creates to see if everything in that iframe has finished loading or not and specifically triggers the print event whenever that happens.
It could be as simple as swapping out the setTimeout being used now with the printDelay duration for jQuery's .load() function that's then assigned to the iframe (possibly having both then use the same, newly called out, function to reduce code bloat while they just use setTimeout or load() depending on if the printDelay value is an integer or the auto/loaded/onload/load/etc. option.)
That way, cases where things load quickly can have print triggered immediately while other times where things take longer to load has it wait no longer than needed for it to print everything in its entirety. This also frees up the circumstance where someone's internet might be having a slow experience that's abnormal while it still completes properly rather than having a partial print (or otherwise needing to set the delay value for everyone to be higher so nobody has an issue which is then not ideal & unfair to those that don't need to wait that long.)
I'm guessing browser caching (which unfortunately doesn't work in this case) & various (more static) use cases so far just haven't had this become a need, but it really does make more sense to just wait for what's being printed to finish loading & just print then rather than having a static delay value that can encounter any number of these pitfalls.
I could really see printDelay being set to this new setting where it just waits for things to finish loading in the iframe before printing be the default while people can then manually set it to be a specific time if they need it for any particular reason.
The text was updated successfully, but these errors were encountered:
@KZeni this is something we are looking into, as we would like to remove all arbitrary timings as they are fragile and problematic. Thanks for the feedback!
What I'm experiencing
I have an asset that needs to be generated each time it's loaded & it can take a while to finish loading in some circumstances. As such, sometimes the print operation is triggered before it's done loading & the asset is not included when it should be whereas some other times everything's all ready to print and the user needs to wait an unnecessarily long time before the print event is triggered.
My proposed solution
I'd love to see something like having
printDelay
support a value ofauto
(oronload
or whatever you want to name it) which then watches the iframe that printThis creates to see if everything in that iframe has finished loading or not and specifically triggers the print event whenever that happens.It could be as simple as swapping out the
setTimeout
being used now with theprintDelay
duration for jQuery's.load()
function that's then assigned to the iframe (possibly having both then use the same, newly called out, function to reduce code bloat while they just usesetTimeout
orload()
depending on if theprintDelay
value is an integer or theauto
/loaded
/onload
/load
/etc. option.)That way, cases where things load quickly can have print triggered immediately while other times where things take longer to load has it wait no longer than needed for it to print everything in its entirety. This also frees up the circumstance where someone's internet might be having a slow experience that's abnormal while it still completes properly rather than having a partial print (or otherwise needing to set the delay value for everyone to be higher so nobody has an issue which is then not ideal & unfair to those that don't need to wait that long.)
I'm guessing browser caching (which unfortunately doesn't work in this case) & various (more static) use cases so far just haven't had this become a need, but it really does make more sense to just wait for what's being printed to finish loading & just print then rather than having a static delay value that can encounter any number of these pitfalls.
I could really see
printDelay
being set to this new setting where it just waits for things to finish loading in the iframe before printing be the default while people can then manually set it to be a specific time if they need it for any particular reason.The text was updated successfully, but these errors were encountered: