Closed Bug 341629 Opened 18 years ago Closed 18 years ago

Opening a link in a new window takes more than 10sec just to create the window

Categories

(SeaMonkey :: General, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: olivier.vit, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.9a1) Gecko/20060611 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.9a1) Gecko/20060611 SeaMonkey/1.5a

On a sempron 2500+ with 1Gbyte of RAM

Reproducible: Always

Steps to Reproduce:
Once started, having a few tabs opened, right click on a link (wait for the menu to draw!) select 'open in a new window', the wait 10sec !! to see the window getting created.
CPU is running almost 100% during these 10 seconds.
This also happens with popups fired by a click of the user.
It seems less obvious when opening in a link in new tab.

Opening a new blank window (through menu or keyboard shortcut) works fine.

Something todo with popup blocker or slow script detection ?



Memory usage is also getting huge these days: 160 Mbytes of memory + the same of VM after one hour of mail/surf.
Can reach 400Mbytes of memory and same of VM after 4-5 hours. Then becomes slower and slower to create new windows...

I'm running latest Flash 9 beta (Flash 9.0 r2) and experienced the same with previous 8.5 beta
Do you have any extensions installed?  Do you see the bug with a clean profile?
Extensions installed are webdeveloper from chrispederick.com and livehttpheaders.
I didn't test yet on a clean profile, but this happens on builds since beginning of June.
 right click on a link (wait for the
> menu to draw!) select 'open in a new window', the wait 10sec !! to see the
> window getting created.
> CPU is running almost 100% during these 10 seconds.
> This also happens with popups fired by a click of the user.
> It seems less obvious when opening in a link in new tab.

I right-clicked the link "View Bug Activity" of this page, selected 'Open Link in New Window', waited about 7 seconds and noticed the CPU maxed for 4 seconds. I see nothing wrong or criticial with those figures as creating a new window takes time and is user-system-resources demanding. 

"Opening new windows, even with reduced features, uses considerably a lot of the user's system resources (cpu, RAM) and involves considerably a lot of coding in the source code (security management, memory management, various code branchings sometimes quite complex, window frame/chrome/toolbars building, window positioning and sizing, etc.). Opening new tabs is less demanding on the user's system resources (and faster to achieve) than opening new windows."
http://developer.mozilla.org/en/docs/DOM:window.open#Usability_issues

Olivier, the document to load may be the issue here as some webpages can have huge, complex, considerable scripts to execute on an onload event and some are known to be very user-system-demanding (creation/manipulation of DOM nodes at loading time). Also, window creation+building and document fetching and loading are 2 asynchronous activities.

I have Livehttpheaders 0.11 extension installed on Seamonkey 1.5a rv:1.9a1 build 2006061509, XP Pro SP2 on PIII 667Mhz here.
Gérard
Thanks for taking the time to test on your side.
I couldn't notice any specific regarding the target URL. It even looks that it takes times before any data gets loaded from the new URL.

Don't you notice a difference with builds a month agao ? 
Don't you notice a difference when opening a new window from ctrl+N instead of a link ? I understand that opening a new window is more resource consumming than opening a new tab. But I don't see why it should be slower from a link than from the menu/shortcut
I don't know if the bug is specific to window management/link management/ or what so ever, but I had to shutdown Seamonkey today after 3 hours of usage because it was just becoming slower and slower(30s to open a popup), and memory usage went to more 400Mbytes (+ 380MBytes fof VM).

Since then, I have been working the same way on the same machine with FireFox 1.5.0.4 with the same extensions and Flash version, and it rocks ! Memory usage is 78MBytes / 65MBytes VM
WFM with Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.9a1) Gecko/20060706 SeaMonkey/1.5a
Maybe was due to some trojan that hijacked into the acrobat the plug-in ?
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.