Closed Bug 48759 Opened 25 years ago Closed 24 years ago

Flash plug-in not able to get multiple pages

Categories

(Core Graveyard :: Embedding: APIs, defect, P2)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: radumas, Assigned: rpotts)

References

()

Details

(Keywords: embed, Whiteboard: [rtm-][nsbeta3-][pdtp2])

Attachments

(6 files)

Flash movies can have multiple actions for a single event. Typically a button in Frame A calls a page for FrameB and FrameC on the same onClick. The current version version of NN and Mozilla only accept one of these events.
--> av, default owner of plug-in API. cc:ing johng who manages Macromedia bundling relationship and troy at MM for info. radumas, could you please provide a URL/test case that demonstrates this problem? That's urgently important for us to be able to reproduce and fix it. Thanks!
Assignee: valeski → av
Keywords: flash
Add'l info emailed by reporter: I attached an example URL: http:ridge.imagineworks.com If you see the flash menubar in the top frame, it calls URLs for each of the two center frames. Works in NN 4.x, MSIE 4.x+, but not NN 6 or Mozilla x.x Actual swf attached: (radumas--many thanks. BTW, please put all info about a bug *in the bug report,* not in private emails that get lost/forgotten. Thanks for all your help on this!):
QA Contact: jrgm → shrir
Putting back the URL (did not mean to delete it; sorry for the noise).
Whiteboard: http://ridge.imagineworks.com/
Adding nsbeta3 keyword. shrir, can you reproduce with latest M18 build?
Keywords: nsbeta3
removing test url from status whiteboard.
Whiteboard: http://ridge.imagineworks.com/
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can see this problem. The left frame does not change content (which it should) when clicked on menu buttons on top. Build:2000081105.
Andrei, can you look into this and try to get a handle on how long this will take to address, and the risk involved, so we can approve or deny it?
OK, to me this one does not look like a plugin issue at all. I'll attach some stuff to make a simple test case and then explain a bit more. Meanwhile, in an attempt to find a right owner cc'ing to mscott and valeski.
Attached patch HTML test caseSplinter Review
To see what's happening put the test plugin dll to the plugins folder and all html files somewhere else. Open test.html, this will invoke the plugin. The plugin has a button clicking which causes NPN_GetURL call three times in a row with three different URLs: 1frame.html, 2frame.html, 3frame.html and with three different targets: 1frame, 2frame, 3frame. Expected result: three new windows with three different contents. If you create a testcase with four frames and the plugin sitting in one and name the rest three 1frame, 2frame, 3frame, then upon button click three frame should be filled with the appropriate contents. And this is exactly what is supposed to happen in the original report with Flash. Actual result: only one window is opened, namely the one corresponding the last NPN_GetURL call, in our case third frame. (In case of frames the third URL will be opened in all frames.) NPN_GetURL eventually maps into WebShell's onLinkClickEvent stuff, that's why I would like Judson's people to look at it. My impression of what is happening is that the last event overrides all previous ones, maybe LoadGroup parenting gets reset every time, I am not familiar with this part of the code. But nsWebShell::HandleLinkClickEvent is called three times with correct URLs and target names which makes me think that plugin part of the code works correctly.
cc'ing rpotts as this may be loadgroup related.
What is happening with this bug? We need to get it in the correct owner's list and decide if it is beta3 material or not, and I cannot tell from the comments. Please update the status of this bug so we can triage it appropriatly.
Changing platform to All and reassigning to rpotts.
Assignee: av → rpotts
OS: Mac System 9.0 → All
Hardware: Macintosh → All
Does this work correctly in Nav 4.7? It sounds like the window targeting is not opening up a *new* window for each unknown target (ie. 1iframe, 2iframe, 3iframe). I bet that the top browser window is being recycled to load each of the 3 html documents... rather than opening up a new browser window for each unknown target. hey mscott, does this sound likely or am I missing the point :-) -- rick
If you open the test case in 4.7 you will see three new windows. And I think this is a logical behaviour.
Hey Rick, that could be one possibility. Another is that the last load is killing off earlier loads before they have a chance to get dispatched to a new target window. when we run new urls we are calling StopURls in nsDocShell which could be aborting the first 2 new frame loads in this case. Does that make sense?
The original report is about a plugin which shows two different contents in separate frames. I don't think we should abort previous loads as this will break the plugin's functionalty.
no that wouldn't be the cause of the original problem.
Flash is the #3 most widely-used plug-in on the web per Hotbot. This is high profile backward compat. Increasing priority to P2. Can we find an engineer to fix this and check in by 9/21?
Priority: P3 → P2
*** Bug 53075 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbeta3+]
pdt agrees p2.
Whiteboard: [nsbeta3+] → [nsbeta3+][pdtp2]
Target Milestone: --- → M18
PDT marking nsbeta3-, nominating for rtm.
Keywords: rtm
Whiteboard: [nsbeta3+][pdtp2] → [nsbeta3-][pdtp2]
Keywords: embed
rtm-, no current activity.
Whiteboard: [nsbeta3-][pdtp2] → [rtm-][nsbeta3-][pdtp2]
Just wanted to share what might be another example of this bug ... http://gilgamesh.psnc.pl/ Select the image in the middle, then [Start] in the new window.
Build: 2000111808 - almost dup'ed this bug - shame to waste the testcase: http://members.netscapeonline.co.uk/valeriegsharp/FlashURLtest/ - a framed site with two rows, the second row having two columns ("lhs" and "rhs"). The top row ("movie") contains the Flash movie, with a button the has two actions - Get URL("lhs.html",window="lhs") and Get URL("rhs.html",window="rhs").
We believe this is fixed. Could someone please verify? verifyme
Keywords: verifyme
well, the original testcase url ie, http://ridge.imagineworks.com/ now works fine(1127 all platforms). However, the other two test url's, http://members.netscapeonline.co.uk/valeriegsharp/FlashURLtest/ and http://gilgamesh.psnc.pl/ provided below still do not work. I guess I will update the url and keep this bug open.removing 'verifyme' keyword.
I don't beleive this is fixed. The tester plugin which sends three consequitive NPN_GetURL calls (see attach.) still does not cause three different navigator windows be opened.
Roland emailed me this update. Thanks Roland! BTW, please put future updates in the bug report itself so we don't lose them. ----- Not fixed. http://www.ridgewine.com/ is my original test site.
Setting mozilla0.8
Target Milestone: M18 → mozilla0.8
Curious, I'm just a wayward 'reporter' of this bug and have been getting these updates for months, but can't see any evidence that work is being done. Is there any likelihood that gecko will be made compatible with Flash? I need to know whether to leave the warning up on my sites (e.g. http://www.ridgewine.com/) or create a downgraded version for Netscape users.
Any activity, resolution to this bug?
Flash crasher or backward incompatibility bug. Nominating for nsbeta1 as high-quality plug-in support is a priority for embedded applications.
Keywords: nsbeta1
I'm not too familiar with the code but I agree with mscott. nsDocShell::StopLoad is being called each time before frame1 and frame2 have a chance the load. They don't even get registered in history so it's not like one loads after another in the same frame. Perhpas StopLoad should only be called if the targets are the same?
Blocks: 65777
IMHO related to (?dupe): bug 61385 : when submitting two forms from JS only one succeeds making dependancy to bug 65777 Loading/Targetting tracker bug.
-> mozilla0.9
juds, target milestone didn't take. moving to m0.9 what is the latest progress on the investigation/fix?
Target Milestone: mozilla0.8 → mozilla0.9
*** Bug 72473 has been marked as a duplicate of this bug. ***
going 091. this *might* be covered by other window targeting bugs rick is working on.
Target Milestone: mozilla0.9 → mozilla0.9.1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
The window targeting issues have been fixed with the patch associated with bug #65777. The test plugin now brings up three new windows.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
yeah this is fixed.. three frames appear when I click the button in the test url above. However, I crash while loading ridgewine.com..that is another bug..will file it seperately. This bug is verified on mac/win/linux 20010517. trunk
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: