Closed Bug 161015 Opened 23 years ago Closed 13 years ago

not all elements are appear on the main page of www.ford.co.uk

Categories

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

x86
Windows 2000

Tracking

(Not tracked)

RESOLVED WORKSFORME
mozilla1.3beta

People

(Reporter: sunlover, Assigned: srgchrpv)

References

()

Details

(Whiteboard: [PL2:NA])

Attachments

(5 files)

www.ford.co.uk does not work well in latest mozilla builds. However it worked with Mozilla 1.0 release. The bug is that sometimes new Mozilla 1.1a+ does not load the whole .swf file and therefore does not feed it to the plugins. Problem description and reproducing: The page www.ford.co.uk uses Macromedia Flash and scripting, so the latest Flash 6 plugin with xpconnect support required. The problem can be seen as not all elements are appear on the page. For example the menu bar near the bottom of the page may be not shown. The bar usually (with Mozilla 1.0) can be scrolled with the Left/Right buttons. To reproduce the bug just start mozilla, clear disk cache (in Preferences) and then type the www.ford.co.uk in the location and press Enter. Page will load but the menu bar may not appear. Problem cause: The movie that is not completely loaded is http://www.ford.co.uk/firefly/spg/images/firefly_1_28_0_14181.swf The size of the file is 23916 bytes. After loading the page the file can be found in disk cache. (just search for FWS signature). And its size there usually smaller that the actual. Last loads produces 22589, 22053 and 21667 bytes files. It should be noted that the whole file was transferred to Mozilla, as seen with a TCP dump utility.
have you installed the most recent Flash-Version (which is required for this page?)
resolving as dup of another ford company flash-scripting bug - it's basically the same flash that is used it seems. *** This bug has been marked as a duplicate of 160072 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
to Kai Lahmann: I indicated in the bug report that the page should be seen with latest Flash 6 plugin. Sure I have installed it. to R.K.Aa: with all respect I do not agree with your explanation of the bug as "ford company flash-scripting bug". The site works with Mozilla 1.0, which always loads the whole flash movie (http://www.ford.co.uk/firefly/spg/images/firefly_1_28_0_14181.swf). Read the original bug report. Anyway I do not believe, that a "ford company flash-scripting bug" would not be the reason of the problem that Mozilla 1.1+ stores only partual content in the cache and the size of the content varies from time to time.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
In latest comment the last sentence should be: "Anyway I do not believe, that a "ford company flash-scripting bug" could be the reason of the problem that Mozilla 1.1a+ stores only partual content in the cache and the size of the content varies from time to time"
a frameset in a frameset, dont you love what those "big agencies" come up with all the time ? anyway, for the logs, i do the the latest r40 flash plugin, and im getting a js error: Error: flashnav.SetVariable is not a function Source File: http://www.ford.co.uk/firefly/spg/spg.asp?SessionID={6690D280-C090-4E90-9CC8-1F0D22502BA2}&page=flash_nav&PageID=&NavID=home&SiteVerID=1&LangID=28 Line: 203
to Michael Gabriel: I guess that the there is no flashplayer.xpt file in the mozilla/components directory. The Flash installer sometimes does not write the file there. I can send it to you in an email. It's only 856 bytes. Also take a look at http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&th=71a0e44787a7c294&seekm=ahgfbr%247f71%40ripley.netscape.com&frame=off They also discussed that Flash installer quirk with the flashplayer.xpt file.
Vitali: I resolved as dup of bug 160072 to avoid spamming people. Did you read the original bug 110441 and the followup bug 159393?
this is indeed a dup, sunlover. pls use the latest flash installer on macromedia.com and make sure u have the 'flashplayer.xpt' file inside plugins folder, it might not directly install to mozilla...
to R.K.Aa: yes, I've read the mentioned 110441 bug. It is similar to the one that I've reported. It even looks like some of the quirks, reported in the 110441, had the same cause. On my view the main problem is that a swf file is not completely passed to plugin. Of course, I can be wrong.
I tested this using the current branch build from 20020805 and Shockwave Flash 6.0 r40. I ensured teh .xpt file was also in the plugins directory and the page loaded just fine. Reporter: is the xpt file in the components directory or the plugins directory - I could not discern which directory it is located. If it is in the components directory, could you move it to the plugins directory and see if that helps. However, if it is in the plug-ins directory, then I'll have to try and come up with another idea! In any event, can you please tell me the version date of the npswf32.dll file and the modified date of the flashplayer.xpt file.
I think there are some misunderstandings here. This bug is not about the Flash Player not installing its .xpt correctly. The problem is that Mozilla does not send the complete .swf data to the plugin. Vitali works in the Flash Player development for a Macromedia licensee and from tracing the plugin, we can clearly see what happens. You can check the size of the .swf in the HTTP header and trace the write stream method and at least we are constantly seeing less bytes to be written to the plugin, hence the movie does not work as expected. As mentioned before, this does not occur on Mozilla 1.0. For 1.1, it happens on all platforms that we've tested.
to Comment #10 From beppe@netscape.com: I checked the bug again with: Mozilla version: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020806 Content of directory C:\Program Files\mozilla.org\Mozilla\Plugins: 06.08.2002 22:24 <DIR> . 06.08.2002 22:24 <DIR> .. 06.08.2002 06:08 17 808 npnul32.dll 03.07.2002 05:06 704 512 NPSWF32.dll 02.08.2002 23:12 856 flashplayer.xpt Plugin info: Shockwave Flash File name: NPSWF32.dll Shockwave Flash 6.0 r40 Procedure: start mozilla, go to www.ford.co.uk. After site has loaded, check the disk cache for the flash movie file. The file contains string: javascript:navclickGts and starts with 'FWS' signature. Look at the file size. It is smaller that should be. Right now I see 22054 bytes, while the actual size of the movie must be 23916 bytes. As achimha@innotek.de commented, I can see that Mozilla does not send the complete .swf data to the plugin. I noticed that the amount of bytes that it actually sends to the plugin is equal to the file size in the disk cache.
Vitali, thank you for detail explanation of the problem, unfortunately I cannot reproduce it using the same mozilla build and the same flash plugin, about:cache?device=disk shows for me: Key: http://www.ford.co.uk/firefly/spg/images/firefly_1_28_0_14181.swf <b> Data size: 23916 Bytes </b> Fetch count: 3 Last Modified: 08/06/02 11:43:27 Expires: 08/06/02 11:43:29 I hope you have enough disk space and your cache is not full. Anyway, could you try clean up the cache and see if it helps? Could you also attach into this bug report captured images of mozilla windows, good one and broken one? Maybe I missed something when I said WFM.
Assignee: beppe → serge
to Comment #13 From serge@netscape.com: Serge, thanks for checking this bug. Yes, I have enough disk space and the cache is not full. >Anyway, could you try clean up the cache and see if it helps? To reproduce the bug you actually have to clear disk (and memory?) cache before going to the www.ford.co.uk The exact steps are: 1) start mozilla, goto Edit/Preferences->Advanced->Cache and clear both caches. Then close the preferences. 2) Goto the www.ford.co.uk site. Wait until it has loaded. You might see something like the fordincorrect.gif (attachment) Ther is no menu bar at the bottom part of the window. 3) Now you can check the cache using about:cache?device=disk I noticed that the http://www.ford.co.uk/firefly/spg/images/firefly_1_28_0_14181.swf is not listed if it was not completely downloaded. But the partual file will be in the cache directory and will have smaller size. 4) Pressing Reload could help and you can get the page and the file completely loaded and see something like ford_ok.gif. In that case the file will be listed in the about:cache?device=disk If I clear the cache again then I again get the incomplete .swf file. I checked that the file completely transferred to mozilla. The request header: GET /firefly/spg/images/firefly_1_28_0_14181.swf HTTP/1.1 Host: www.ford.co.uk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020806 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai n;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1 Accept-Language: en-us, en;q=0.50 Accept-Encoding: gzip, deflate, compress;q=0.9 Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300 Connection: keep-alive Cookie: FFGUID=%7BC0B71BE8%2D351E%2D4557%2DA5C7%2DB24E7CBC49B8%7D; ASPSESSIONIDQGGGGBKK=JDHABMKCLKCOLCFMAMIHJJCL HTTP header (reply) for the file is: HTTP/1.0 200 OK Server: Microsoft-IIS/5.0 Date: Tue, 06 Aug 2002 20:22:01 GMT Content-Type: application/octet-stream Accept-Ranges: bytes Last-Modified: Tue, 06 Aug 2002 20:03:22 GMT ETag: "b2611851843dc21:12c2" Content-Length: 23916 X-Cache: MISS from orion.utk.ru Connection: keep-alive Last bytes in the file as seen in the TCP stream (last packet from a tcp dump) are: 00B0 0A 14 00 00 00 62 75 69 6C 64 53 63 72 6F 6C 6C .....buildScroll 00C0 54 65 78 74 4C 6F 6F 70 00 40 00 40 00 40 00 3F TextLoop.@.@.@.? 00D0 03 07 00 00 00 81 02 00 0B 00 06 00 40 00 00 00 ............@... The file size in disk cache directory however was 22084 bytes.
thanks Vitali, investigating...
Serge: I can now reproduce it using the nightly mozilla build, but not the Netscape build.
Thanks Beth, I see it in mozilla 20020806 optimized build too, updating my debug three now.
Confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Priority: -- → P3
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.2alpha
I cannot repro this in 20020806 debug build & Shockwave Flash 6.0 r40 on w2k:( but I'm getting a lot warnings in JS console.
hmm, the strange thing is I cannot reproduce the problem using mozilla 20020806 optimized build anymore, yesterday I've seen the broken page with the same build, however. Is content of http://www.ford.co.uk got changed? Vitali are you still seeing this problem?
to Comment #22 From serge@netscape.com: Yes, I've just tested and reproduced this bug again. Did you clear the cache before trying to reproduce the bug?
yes, I did clean up the cache. BTW: do you see any output into javascript console?
The bug still reproduced here. You said: >hmm, the strange thing is I cannot reproduce the problem using mozilla 20020806 >optimized build anymore, yesterday I've seen the broken page with the same >build, however. Does this mean that you see the the flash movie completely loaded in the cache or just that you see all elements on the page? I would look to the file in the cache rather than at the page. I have got just 'document.layers has no properties' JS error there. The same error happens in Moz1.0 where the site works ok.
I've checked out both the flash movie and the actual file size in the cache, both look good.
Serge, would you please zip the binaries that you use and put it somewhere on ftp or like that so I could download and test it here? I assume the binaries are for Win32. Also, as I noted before, the swf file size varies from time to time. I would suspect some kind of lack of coordination between two threads. May be you were lucky to get it right a few times, so the stream was downloaded completely.
in comment #12 you provided mozilla version you were using: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020806 so, to be in sync I've downloaded & installed the binaries from ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-08-06-14-trunk/mozilla-win32-installer-sea.exe I'm using the same as yours Shockwave Flash 6.0 r40, also I've tried newer Flash 6.0 r47, both works for me. I can try to attach flash6-r47.xpi into this bug report, but I'm not sure if it's possible to attach 400+K file into bugzilla, would you like me to email it to you instead?
to Comment #28 From serge@netscape.com: Hi Serge, >I've downloaded & installed the binaries from >ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-08-06-14-trunk/mozilla-win32-installer-sea.exe I have downloaded the binaries. It turned out that I've been using binaries with build ID 2002080604, while the url contained 2002080614. Anyway the 2002080614 binaries have the same bug. >I can try to attach flash6-r47.xpi into this bug report, >would you like me to email it to you instead? Sure, you can send it to sunlover@anduin.net. However, this bug is not a plugin bug, the same plugin works fine with Mozilla 1.0. There is something that was broken in Mozilla 1.1. All versions of Mozilla 1.1 (1.1a, 1.1b and a few latest nightly builds) that I tried on different platforms exhibit the bug. While Mozilla 1.0 (and 1.0rc3) always worked.
well, I'm puzzled:( what's your Cache: "Compare the page in the cache to the page on the network:" setting? what's your HTTP Networking: "Enable Pipelining" setting? are you using proxy?
to Comment #30 From serge@netscape.com: >what's your Cache: "Compare the page in the cache to the page on the network:" setting? >what's your HTTP Networking: "Enable Pipelining" setting? are you using proxy? I do not touch the preferences after Mozilla installation, so they all should be defaults. Cache "Compare ..." is "When the page is out of date" "HTTP networking" settings are: "Use HTTP 1.0" "Enable keep alive" on "Enable pipelining" off Proxy is not enabled in Mozilla ("Direct connection to Internet"). But the provider uses transparent proxy (this can be seen in the Comment #15 HTTP reply). I should note again that I have checked that the whole file is transferred to Mozilla. This was checked a few times. The connection uses 56K modem, speed is about 4Kb/s. Again, the file size in the cache and the amount of data delivered to the plugin can vary, that clearly indicates that there are some kind of timing issues. There is a possibility that under particular circumstances the file will be completely downloaded. In your case I would try the repeat the steps (clear disk and memory cache, go to www.ford.co.uk) a few times with different system and internet connection usage. For example, start mozilla build process, which should use a lot of CPU and disk, or download a big file at the same time as accessing www.ford.co.uk. Also, if you are unable to reproduce the bug, then I could help you. Do a debug build, trace there the functions those deliver data to disk cache and plugins. I'll run the debug build here and we will clearly see what happens.
Vitali, I suspect this is the same issue as a bug 166613, it's very likely on slow connection some plugins stream can be cancel before it completes. The fix for bug 166613 is checked in, could you please verify if this bug is resoled also. Thanks.
Serge, with Mozilla {Build ID: 2002101616} the bug still exists.
Vitali, could you please provide a log file by setting env vars: SET NSPR_LOG_MODULES=Plugin:5,PluginNPN:5,PluginNPP:5,nsHTTP:5 SET NSPR_LOG_FILE=C:\pluginlog.txt
Attached file pluginlog.zip
from Vitali's e-mail >The log attached. > >I started mozilla, then cleared both memory and disk cache in preferences >and then go to www.ford.co.uk. > >22590 bytes (should be 23916) were delivered >to the plugin (/firefly/spg/images/firefly_1_28_0_14181.swf). > >Let me know if you need any additional information. > >Thanks, >Vitali.
... 0[2b60c8]: Preparing to write data into the cache [uri=http://www.ford.co.uk/firefly/spg/images/firefly_1_28_0_14181.swf] 0[2b60c8]: nsHttpChannel::OnDataAvailable [this=107f778 request=10f52cc offset=0 count=238] ... 2[2b6200]: mSource->Read [rv=80470007 count=1986 countRead=0] 2[2b6200]: nsHttpTransaction: mSource->Read() returned [rv=80470007] well, the next call w/ target=_self causes all active network channels to be canceled:( target=_self looks strange here, it's equal to loading new url in current window, in which case all previous content should be deleted. ==>0[2b60c8]: NPN_GetURLNotify: npp=fe1f0c, target=_self, notify=2, url=javascript:navLoaded(); 2[2b6200]: nsHttpTransaction: listener returned [rv=0] 2[2b6200]: mTransaction->OnDataReadable() returned [rv=0] 2[2b6200]: nsHttpTransaction::OnStatus [this=10f52c8 status=804b0006] 0[2b60c8]: nsHttpChannel::OnDataAvailable [this=107f778 request=10f52cc offset=22054 count=536] and actual cancellation happened in the next call, with len = 22054 + 536 == 22590 ==>0[2b60c8]: nsHttpChannel::Cancel [this=107f778 status=804b0002] 0[2b60c8]: nsHttpTransaction::Cancel [this=10f52c8 status=804b0002] 0[2b60c8]: nsHttpHandler::CancelTransaction [trans=10f52c8 status=804b0002] 0[2b60c8]: nsHttpConnection::OnTransactionComplete [this=105f530 trans=10f52c8 status=804b0002] 2[2b6200]: nsHttpConnection::OnStopRequest [this=105f530 ctxt=0 status=804b0002] 2[2b6200]: nsHttpTransaction::OnStopTransaction [this=10f52c8 status=804b0002] 2[2b6200]: nsHttpHandler::ReclaimConnection [conn=105f530(www.ford.co.uk:80) keep-alive=0] 2[2b6200]: closing connection: connection can't be reused 2[2b6200]: active connection count is now 0
moving to 1.3 beta
Target Milestone: mozilla1.2alpha → mozilla1.3beta
>well, the next call w/ target=_self causes all active network channels to be >canceled:( >target=_self looks strange here, it's equal to loading new url in current >window, in which case all previous content should be deleted. Flash calls javascript methods by calling NPN_GetURLNotify with a "javascript:something" URL. Flash can specify target window to load an url to. If the target window was not specified all Flash versions use "_self" target: if ( window[0] == 0 ) { window = "_self"; } This is why we can see a "call w/ target=_self" Note that this is behaviour of all Flash versions from 4.x to 6.x I would think that Mozilla should process "javascript:*" urls with "_self" target in a different way. may be it should just call javascript code and do not treat it as "loading new url".
www.ford.co.uk redesigned, now does not use Flash. Still doesn't work in Mozilla, though...
This is still a problem as of FFv3. I've tried with all addons disabled, cleared cache, etc. See screen shot attached. There are no specific error messages in the error console either. The only ones that showed up are below: Warning: The "coords" attribute of the <area shape="rect"> tag is not in the "left,top,right,bottom" format. Source File: http://www.ford.co.uk/undefined/undefined/undefined/rt_home/home/-/-/- Line: 0 Source Code: coords="0,243,594,0" Warning: The "coords" attribute of the <area shape="rect"> tag is not in the "left,top,right,bottom" format. Source File: http://www.ford.co.uk/undefined/undefined/undefined/rt_home/home/-/-/- Line: 0 Source Code: coords="603,56,734,5"
QA Contact: shrir → plugins
The website references here is quite different now and is WFM.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago13 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: