Closed Bug 47968 Opened 25 years ago Closed 25 years ago

Browser UI unusable (de facto hang) on page with Flash after loading

Categories

(Core Graveyard :: Plug-ins, defect, P2)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: j.frandsen, Assigned: peterlubczynski-bugs)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [nsbeta3-])

Steps: 1) Go to http://www.cocacola.com 2) It will say "Loading" with a progress indicator 3) Once loaded, a Java application is run, where the mouse controls certain things - looks great and works great. 4) HOWEVER: No links can be pressed at this point, and no matter what URL is written in the address bar, it is ignored. The application keeps running - nothing crashes - but Mozilla is made useless. (JAVA issue probably) (doesn't happen with ns4.7)
Sorry, The build is M17 - 2000080712.
Confirming on M17/Linux. Also had one case in which the browser crashed after dismission the "plugin downloader" dialog. May be a DOM issue.
you have to wait enough nex page with Flash to be loaded
this is a flash issue I think. it works form me 080808 on NT and 98 as well as 080808 Mac build on MacOS 9
Assignee: asa → av
Component: Browser-General → Plug-ins
QA Contact: doronr → shrir
I do't get any crash on this page (build 2000080808m18 windows). Will see on mac today.
I meant..I don't get any crash...
wfm 080908, win95
Just tried nightly build 080908.. doesn't work. :( After having gone to the page it is impossible to leave again - e.g. writing a different address in the URL field has no effect. Clicking on anything on the CocaCola page has no effect. Mozilla has not crashed though. After quitting it, I sometimes get another Mozilla window (that wasn't there before) containing the (cocacola) link I clicked (for instance the cap). Weird. I can reproduce this every time. I did this on a clean system.
Jacob do you see this on NT? And what is the speed of your machine?
I'll also add that, while the browser GUI doesn't work, the keyboard shortcuts do work (i.e. alt+[ and alt+] will make the browser go back and forward).
I'm running NT4.0SP6a on a PIII/433.. 128MB RAM - not needing resources really. Retrying a couple of times, it seems that clicking the cap of the big coke bottle brings mozilla to this state where alt+left/right, the GUI, nothing works. If you just go to the page and leave it again, it seems to work. However, if you wait (quite a while - like 20 seconds) the small window for the cap finally appears and everything is fine. So it works.. it's just very very slow and while you're waiting (after clicking the cap) you can do nothing but wait - which is not nice.
Confirming, adding flash keyword. Could someone summarise what this bug is now about, exactly? Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: flash
I suppose the "bug" here is that the browser becomes functionally unresponsive while waiting/executing/whatever some flash. As described, clicking the cap will produce this loooooong delay.. eventually, you get to the cap page, but while waiting for it (and trying not to lose your patience), the browser is.. let's say "hanged"? In NS, the cap page loads and views right away.
Adding crash keyword and nominating nsbeta3 as this is both a de facto crasher (renders browser UI unresponsible) as well as high profile backward compatibility. Setting P2, eligible for 9/21 checkin. Andrei, we need to get you some help on these flash bugs. Changing Summary from "Hang browser after loading" to "Browser UI unusable (de facto hang) on page with Flash after loading".
Keywords: crash, nsbeta3
Priority: P3 → P2
Summary: Hang om page after loading → Browser UI unusable (de facto hang) on page with Flash after loading
Whiteboard: nsbeta3+
Marking nsbeta3+.
There is no crash, no hang, it works, but really slow. Not sure if this should be nsbeta3+ When it displays the page it takes almost 100% of processor resource as 4.x does too. Interesting thing is that it releases it when you switch focus to another window. I need ideas on what this could be. Adding some people to the cc list.
Status: NEW → ASSIGNED
PDT thinks this is nsbeta3- per av's last comments. It would certainly be a P2/nsbeta3+ if it really did hang.
Whiteboard: nsbeta3+ → nsbeta3-
Does not hang but it is very slow definitely (20000920m18)
Keywords: 4xp
Marc, can you take a look at this.
Assignee: av → attinasi
Status: ASSIGNED → NEW
Whiteboard: nsbeta3- → [nsbeta3-]
In Netscape6 PR3 (candidate 092908) I do see a hang. The page comes up and there is a constant scrolling pane that looks fine, however if I click on the cap, for example, nothing happens and from then on I cannot use the browser (menus do not work, location bar not accessable, etc.) I gave if 10 minutes to free up, but it never did. Had to close the browser and restart it to recover. I'll try to determine where we are spinning, or if it is merely the plugin being buggy.
Status: NEW → ASSIGNED
Over to peter to look at - I'm too busy to give this it's due attention right now.
Assignee: attinasi → peterlubczynski
Status: ASSIGNED → NEW
Is this a Linux only bug? Can someone with Linux try this out? I just tried (in NT, yesterday's pull) clicking on the cap as noted and right away I get a popup window asking me to download the screen saver, no delay, and I don't loose my UI functionality. Tried a few other links and it works okay. Has this gone away?
At least the windows branch build 20000929 still shows this problem. Not sure about the trunk.
Ahh...looks like it could be a Flash 4 problem. I just downloaded a Flash (with Director) freshly from Macromedia, pointed to my Mozilla directory during install, and it works beautifully (nice site!) on NT. Then I tried another instance of Mozilla with the Flash 4 plugin installed and I see the behavior described here. I'll go and confirm with Marc. Shrir, can you try this with a fresh install of Flash?
I retried with a new installation of flash.This has improved a lot. Both 4.7 and 6.0 take up 100 % of system resources but this website is working better than as it was initially reported. Jacob, can u pls try this webpage again and comment?
I just confirmed with Marc and it does appear that the Flash 5 plugin works correctly whereas the Flash 4 plugin doesn't. I am seeing the 100% CPU cycles but the rest of the UI still is responsive. Eric, We currently ship with the Flash 4 plugin. Can we ship with the Flash 5 plugin instead? What should I do with this bug?
johng manages the Macromedia/Flash bundling relationship; I only manage the Mozilla Plug-in API itself. cc:ing johng for info about whether we could bundle Flash 5 rather than Flash 4. (Does that help this bug?)
Yes, I believe using and including Flash 5 (instead of 4) with our product should close out this bug unless there is another testcase that doesn't work with Flash 5 (none found yet).
Status: NEW → ASSIGNED
adding RTM to keyword. Haven't heard from johng about including Flash 5.
Keywords: rtm
Just got confirmation from johng that we will include Flash 5 and therefore this bug will be fixed. bugzilla 56284 (previously bugscape 2791) for Win bugscape 2861 for Mac bugscape 2865 for international
Flash player 5.0 is in today's windows branch build(2000101308). Marking this fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
marking this VERIFIED. WOrks smoothly with 11/08 rtm builds.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.