91617 - window.open( ) fails if memory cache is set too small

Status: RESOLVED WORKSFORME

(Core :: Networking: Cache, defect)

Description

[hirata masakazu]

2001071913 trunk for MacOS
Goto URL.
Click one of the images.
Result:No pop up windows show up.
Expected result:Pop up window should show up and then crash (due to bug 89367)
or play video.
This does not happen in 071809 build, which results in crash of bug 89367.
I am aware that there have been a lot of window.open( problems, and there might
be a dupe, but this particular problem started in this build.

Comment 1

[hirata masakazu]

WFM in 2001072304 trunk.

Comment 2

[hirata masakazu]

REGRESSION
2001072618trunk for MacOS9.1.

Comment 3

[hirata masakazu]

The regression occurred in this build but not in yesterday's, therefore the
offending check in must have taken place between 2001072508 and 072618 in trunk.

Comment 4

[hirata masakazu]

I have realized that setting memory cache too small causes window.open to fail.
It was set at 16 kb to test another problem.
Changing Summary and downgrading the severity.

Comment 5

[Johnny Stenback (:jst)]

window.open() should never rely in any way on the cache, the cache must be doing
something wrong if changing the size of the cache affects how window.open()
works. Over to the cache component.

Comment 6

[gordon]

Couldn't I also say that window.open() must be doing something wrong if changing
the cache size somehow affects its behavior?

It's likely to be an ImgLib problem.  With only a 16kb memory cache, there is
probably a lot of thrashing going on with the image cache.  From my
understanding of ImgLib2, however, I don't think it should fail to draw even if
it can't hold an image in the cache.  Cc'ing Pav for his comments.

While we should break with just a 16kb memory cache, there's probably no point
having one that small.

Comment 7

[hirata masakazu]

I have filed several window failure problems including this one and bug 92051,
which ultimately results in bug 73893.
My question is why it can not be made so that some default window is drawn (or
virtually in the backend) and its parameter table updated before Mozilla tries
to gather information to draw the actual window. Since it is listed under Task
menu, some table that keep track of the windows has been updated by the time it
waits for those information, it should not be so difficult.

Comment 8

[hirata masakazu]

An interesting observation.
If I set the memory cache and disk cache = 8192 kbytes in  preferences and click
the "Listen Online" link in http://www.wrni.org or http://www.wbur.org ,
the pop up window is not drawn, but correct window title is listed under task
menu, and the popup window functions correctly with Windows Media Player plugin.
You can select the undrawn window from Task menu and command+W to close it.
If the cache size are much smaller, say 2048 kb each, the pop up window can not
become functional nor window title listed under Task menu.

Comment 9

[hirata masakazu]

WFM in 2001110612 trunk.
Similar bug is bug 88259, which is WFM, too.