simple XUL iframe example hangs Mozilla on startup (complex site)

RESOLVED WORKSFORME

Status

()

Core
XUL
RESOLVED WORKSFORME
17 years ago
10 years ago

People

(Reporter: rvj, Assigned: Peter Trudelle)

Tracking

Trunk
Other
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

(Reporter)

Description

17 years ago
The attached simple shell.xul example hangs Mozilla when invoked 
using "C:\Program Files\Mozilla\Seamonkey\mozilla.exe" -chrome 
file://c:/windows/desktop/shell.xul

The target website is fairly complex however the same site loads correctly via 
Mozilla if URL entered via Mozilla address bar.

Does  XUL need some initialisation routines ( clearing memory ) for a simple 
iframe window?
(Reporter)

Comment 1

17 years ago
Created attachment 24756 [details]
simple XUL iframe example hangs Mozilla
(Reporter)

Comment 2

17 years ago
this may be a javascript top versus parent issue - please ignore for time being
(Reporter)

Comment 3

17 years ago
OK have changed any references from top to parent but Mozilla still hanging 
when launched using command line syntax.

It works fine when entering the file URL for shell.xul in the address bar which 
is file:///C:/WINDOWS/Desktop/shell.xul


So is there anything wrong with the command line syntax for a shortcut (that I 
cant see)

"C:\Program Files\Mozilla\Seamonkey\mozilla.exe" -chrome 
file://c:/windows/desktop/shell.xul

I am using release 0.7.

(Reporter)

Comment 4

17 years ago
PS I thought it might be a change in command line syntax. (It seems with the 
0.7 installer.exe version that quotes are required around the application path 
rather than the arguments)

Anyway I have tried with other target pages using the same syntax and they work 
fine. e.g "C:\Program Files\Mozilla\Seamonkey\mozilla.exe" -chrome 
file://c:/windows/desktop/shell4.xul

So to recap,  my test site loads when the XUL file path is entered in the 
address bar but not via the command line (windows shortcut)


Wierd?


Comment 5

17 years ago
The URL within the <iframe> doesn't exactly load for me when I enter it into 
the Location: bar. But it doesn't hang. 

However, yes, starting with -chrome file:///c:/foo.xul with that simple bit
of XUL (just an iframe in a window) does hang the browser. When I break in 
the debugger (on win2k) it's always in style code resolving style contexts,
but it's a fairly odd stack. I was going to describe it, but I can't :-]
I'll just attach one of them here.
-> Style System for a look
Assignee: trudelle → pierre
Status: UNCONFIRMED → NEW
Component: XP Toolkit/Widgets: XUL → Style System
Ever confirmed: true
QA Contact: jrgm → ian

Comment 6

17 years ago
Created attachment 24860 [details]
iframes, and events, and reflows, and style contexts ...

Comment 7

17 years ago
oh my.

(sorry, couldn't resist)
(Reporter)

Comment 8

17 years ago
OK I think I've found a partial solution. Its something to do with the box 
system. If a fixed sized box contains the iframe then it seems to partially 
work but is

a) EXTREMELY slowly....
b) and image load events are not being recognised


If flex is used to define the containing box then Mozilla hangs. Now the BOX 
system documnetation is quite specific about not using percentages to define 
inner box elements but I suspect this problem is being caused by the use of 
percentages in the actual document (not the XUL).

Is this possible?


(Reporter)

Comment 9

17 years ago
Created attachment 24882 [details]
fixed sized containing box (partial solution)
(Reporter)

Comment 10

17 years ago
I ve tried a few more things and I think Ive narrowed it down to a problem with 
vertical flex. 

Have attached a new enclosing box example which works on the horizontal but 
have not found a means of setting the iframe height equal to window height 
without Mozilla hanging.

However the problem with image load events being ignored (or not firing ??) 
remains. Should this be a sperate bug report?


PS John M. indicated that the test page URL did not load. If Mozilla has had an 
error then it appears necessary to close the browser and retry - this normally 
works although sometimes it seems ncessary to clear disk and memory cache via 
Advanced prefs.  Hope this helps.
(Reporter)

Comment 11

17 years ago
Created attachment 25143 [details]
vertical flex problem in XUL
(Reporter)

Comment 12

17 years ago
Seems this is probably two separate XUL related bugs

a) vertical height of body (body tag background color not 100% of window area)
b) number of resize events generated during load or window resize

The SIMPLIFIED test case (resize.htm and resize.xul) show both problems.

1. If resize.htm is opened via Mozilla (File/Open) no resize events are 
generated. i.e. Blue background 100% of window area

2. If resize.xul is opened via Mozilla (File/Open) no resize events are 
generated but blue background only about 150px in height


3. if resize.xul opened via shortcut such as "C:\Program 
Files\Mozilla\Seamonkey\mozilla.exe" -chrome 
file:///c:/windows/desktop/resize.xul then  ***** 129 ***** resize events are 
generated on load and blue background approx 150px in height. 

Resizing (horizontal) generates approximately another 100 resize events.

Good luck!!!


(Reporter)

Comment 13

17 years ago
Created attachment 25257 [details]
simplified test case resize xul
(Reporter)

Comment 14

17 years ago
Created attachment 25258 [details]
simplified test case resize.htm

Comment 15

17 years ago
Resize problems: reassigned to XPToolkit/XUL.
Assignee: pierre → trudelle
Component: Style System → XP Toolkit/Widgets: XUL
QA Contact: ian → jrgm

Comment 16

17 years ago
Er, well it was sent from XPToolkit to Style because the reproducible hang
was in Style System code. 

But that was many moons ago, and I don't hang on the first attachment launching
as a -chrome url.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.