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

RESOLVED WORKSFORME

Status

()

P3
major
RESOLVED WORKSFORME
16 years ago
7 years ago

People

(Reporter: sunlover, Assigned: srgchrpv)

Tracking

Trunk
mozilla1.3beta
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL2:NA], URL)

Attachments

(5 attachments)

(Reporter)

Description

16 years ago
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?)

Comment 2

16 years ago
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
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 3

16 years ago
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 → ---
(Reporter)

Comment 4

16 years ago
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"

Comment 5

16 years ago
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
(Reporter)

Comment 6

16 years ago
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.

Comment 7

16 years ago
Vitali: I resolved as dup of bug 160072 to avoid spamming people.
Did you read the original bug 110441 and the followup bug 159393?

Comment 8

16 years ago
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...
(Reporter)

Comment 9

16 years ago
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.

Comment 10

16 years ago
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.

Comment 11

16 years ago
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.

(Reporter)

Comment 12

16 years ago
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.
(Assignee)

Comment 13

16 years ago
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
(Reporter)

Comment 14

16 years ago
Created attachment 94228 [details]
Good image of the www.ford.co.uk site
(Reporter)

Comment 15

16 years ago
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.
(Reporter)

Comment 16

16 years ago
Created attachment 94229 [details]
Broken image of www.ford.co.uk
(Assignee)

Comment 17

16 years ago
thanks Vitali,
investigating...

Comment 18

16 years ago
Serge: I can now reproduce it using the nightly mozilla build, but not the
Netscape build.
(Assignee)

Comment 19

16 years ago
Thanks Beth, I see it in mozilla 20020806 optimized build too,
updating my debug three now.

Comment 20

16 years ago
Confirming
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

16 years ago
Status: NEW → ASSIGNED
Priority: -- → P3
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.2alpha
(Assignee)

Comment 21

16 years ago
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.
(Assignee)

Comment 22

16 years ago
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?
(Reporter)

Comment 23

16 years ago
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?
(Assignee)

Comment 24

16 years ago
yes, I did clean up the cache.
BTW: do you see any output into javascript console?
(Reporter)

Comment 25

16 years ago
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.
(Assignee)

Comment 26

16 years ago
I've checked out both the flash movie and the actual file size in the cache,
both look good.
(Reporter)

Comment 27

16 years ago
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.
(Assignee)

Comment 28

16 years ago
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?
(Reporter)

Comment 29

16 years ago
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.
(Assignee)

Comment 30

16 years ago
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?

(Reporter)

Comment 31

16 years ago
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.
(Assignee)

Comment 32

16 years ago
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.
(Reporter)

Comment 33

16 years ago
Serge, with Mozilla {Build ID: 2002101616} the bug still exists.
(Assignee)

Comment 34

16 years ago
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
(Assignee)

Comment 35

16 years ago
Created attachment 103406 [details]
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.
(Assignee)

Comment 36

16 years ago
...
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

Comment 37

16 years ago
moving to 1.3 beta
Target Milestone: mozilla1.2alpha → mozilla1.3beta
(Reporter)

Comment 38

16 years ago
>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".

Comment 39

16 years ago
www.ford.co.uk redesigned, now does not use Flash. Still doesn't work in
Mozilla, though...

Comment 40

11 years ago
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"

Comment 41

11 years ago
Created attachment 326457 [details]
Screenshot showing ford.co.uk as seen in IE v6.0.2xx (as is expected to be seen generally)

Comment 42

11 years ago
Created attachment 326459 [details]
Screenshot showing ford.co.uk as seen in FF v3.0
QA Contact: shrir → plugins

Comment 43

7 years ago
The website references here is quite different now and is WFM.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.