1. maximize your apprunner window 2. go to http://cbs.marketwatch.com/news/current/snapshot.htx?source=htx/http2_mw 3. see the page gets layed out correctly, and all of the sudden content shifts to the right... 4. hit reload, same thing happens 5. resize window, content doesn't get reflow

Appears to be a table problem. This looks similar to bug #14489

It appears to be a problem caused by the alt text is displayed instead of the sidebar images, on unsuccessful retrieving. The image name is very long and that's what pushes the table too wide. Table is fixed width so it shouldn't be resized on window resize.

Yes, the <img src="http://ad.doubleclick.net/ad/cbsmw.button.com/SIDEBAR_BUTTONS;sz=88x31;kw=D BCC;tile=4;ord=1864641213378545414" width="88" height="31" vspace="5" border=0> is causing the column to be too wide. Reassigning to Kipp.

Well, the real problem is that we can't load that image with necko. So I'm bouncing this one over there to be fixed. The layout after the image stops being an image is reasonable.

Came we bump up the target milestone for this bug? like, by beta or something? This link is off of my.netscape page... CBS MarketWatch, and most of their pages are having this layout problem.

*** Bug 16812 has been marked as a duplicate of this bug. ***

Rick, can you check out why the socket transport isn't loading the image in the attachment file that Kipp gave: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=2289 Also, I'm seeing the text bump over after attempting to load this image, displaying this text: SIDEBAR_BUTTONS;sg=88x31;kw=DBCC;tile=2;ord=186443241356908581748 so maybe there are 2 bugs here.

It appears that the image URL gets redirected twice... first to - Location: http://ad.doubleclick.net/viewad/249085-buygolf_88x31.gif and then - Location: http://creatives.doubleclick.net/viewad/249085-buygolf_88x31.gif%3Bsz%3D88x31%3B kw%3DDBCC%3Btile%3D1%3Bord%3D1865239613507480 However, it appears that the image is actually loaded by HTTP as a 43 byte image/gif stream... I'll need to track down where the data goes from there...

Looking at the HTTP log... The first redirect told mozilla to download (1) http://ad.doubleclick.net/viewad/249085-buygolf_88x31.gif but it attempted to download (2) http://ad.doubleclick.net/viewad/249085-buygolf_88x31.gif;sz=88x31;kw=DBCC; tile=1;ord=186523961350748063055 (Looks like an URL parsing error) When I view (1) in Nav4 I get the correct picture. When I view (2) in Nav4 I get an 1x1 gif (43 bytes length). And that is how it happens in Mozilla too! The difference is that when I load the URL Mozilla tried to get http://ad.doubleclick.net/ad/cbsmw.button.com/SIDEBAR_BUTTONS;sz=88x31; kw=DBCC;tile=1;ord=186523961350748063055 that does get an advertisement image on Nav4, but on Mozilla I get a 404 Not Found error (which I don't copy here because Copy doesn't work...) If I hit reload I got the error message back, but if I click on the URL bar and press ENTER I got the 1x1 image...

Changing summary from: page not rendering correctly to: cbs.marketwatch.com images don't load Gagan can you take a look at this one for Rick? Thanks.

this is our new anti-ad-banner feature for m11.;-) moving to m12. let me know if I've missed something.

Moving Assignee from gagan to warren since he is away.

I think there are two bugs here: 1. An urlparser bug 2. Something in layout which damages links, highly unpredictable ... The urlparser bug happens because the current parser does not account for multiple params, the last one currently wins, the constructed url is false and mapped to the grey 1x1 gif. Some time ago Kipp fixed this problem, but the solution was rejected by Gagan. I have revived that stuff locally in a little modified version and the page loads successfully. However sometimes bug 2 still happens ...

Moving what's not done for M12 to M13.

As far as I can tell, ALL Doubleclick.com ad redirects use this ";" multi-parameter syntax... probably other ad servers do too. For reference, the use of multiple parameters separated by ";" is defined in section 3.3 of RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax", <URL:http://www.ietf.org/rfc/rfc2396.txt>. Quoting: >3.3. Path Component > >The path component contains data, specific to the authority (or the >scheme if there is no authority component), identifying the resource >within the scope of that scheme and authority. > > path = [ abs_path | opaque_part ] > > path_segments = segment *( "/" segment ) > segment = *pchar *( ";" param ) > param = *pchar > > pchar = unreserved | escaped | > ":" | "@" | "&" | "=" | "+" | "$" | "," > >The path may consist of a sequence of path segments separated by a >single slash "/" character. Within a path segment, the characters >"/", ";", "=", and "?" are reserved. Each path segment may include a >sequence of parameters, indicated by the semicolon ";" character. >The parameters are not significant to the parsing of relative >references.

*** Bug 20026 has been marked as a duplicate of this bug. ***

*** Bug 23097 has been marked as a duplicate of this bug. ***

Changing Component from HTMLTables to Networking.

*** Bug 22715 has been marked as a duplicate of this bug. ***

assigning this bug to me per Warrens request

Fixed by Andreas' changes that I just checked in.

reopened because of backout

This will not make it into M13

Clearing FIXED resolution due to reopen.

*** Bug 25340 has been marked as a duplicate of this bug. ***

*** Bug 25355 has been marked as a duplicate of this bug. ***

Putting on PDT+ radar for beta1.

finally fixed

Since component has been changed to networking, I 'm reassigning QA contact to tever.

verified: NT 2000021408