On Apr 19, 9:23 am, krithika <[EMAIL PROTECTED]> wrote: > On Apr 18, 11:11 pm, Boris Zbarsky <[EMAIL PROTECTED]> wrote: > > > > > krithika wrote: > > > Q1 : Will reflow occur because dom window has changed? > > > Reflow is usually asynchronous. So it depends on when you open print > > preview. > > > > Q2 : Is it possible to do a forced reflow from my java application > > > which embeds the gecko engine without doing a webnavigation.loadurI > > > Yes. You can either explicitly call nsIDocument::FlushPendingNotifications > > with > > the right arguments, or get a property that calls it > > (document.body.offsetWidth > > is good for HTML). > > > > When all will reflow occur other than these ? > > > 1. Window is resized > > > 2. dom modification via script. > > > All sorts of cases that trigger reflow... I'm not sure I follow the > > question. > > > -Boris > > Hi, > > Thanks for all the help you have offered so far.I tried > nsIDocument->FlushPendingNotification() with all the options provided in > > mozFlushLayout.h.I did this inside exit PrintPreview code in > nsDocumentViewer.cpp.But it did not work. > > Where should I call this from? > > Iam unable to call FlushPendingNotifications from my embedded java > code as javaxpcom has no provision (Correct me if Iam wrong). > > Can you just give me some more details on get a property that calls it > document.body.offsetWidth.?I did not understand that completely? > > regards, > Krithika
As Boris pointed calling printPreview again causes reflow of the modified page.I had problems as I was running on a remote machine. Now things work as expected. Thanks for all the help, Krithika _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
