Closed Bug 2693 Opened 27 years ago Closed 27 years ago

enabling pics causing some problems on many pages

Categories

(MozillaClassic Graveyard :: PICS, defect, P1)

Product:
MozillaClassic Graveyard
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: matt, Assigned: nisheeth_mozilla)

Details

(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #314034 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=314034 Imported into Bugzilla on 01/26/99 22:32) aug13th build goto pics page click on setup click on new user on setup page setup picts rating. The default works. save changes at bottom of page goto http://warp/js/brendan.jpg If image loads hit reload image disappears
I had problems with a couple other secure sites also - can't login at www.optionslink.com, and www.techfed.org web-branch.
Squid and I found a handful of sites that are affected by this bug when running with pics: http://arya.mcom.com:82/ hit the search link in the corner http://www.optionslink.com/ click on any link https://webbranch.techfed.com/ keeps loading page
Adding pauld and chofmann to the cc: list
Here are the various prefs that show up in prefs.js user_pref("browser.PICS.password", "ZDhlNzU4N2E2ZDc4MTNiMTNiMzExYmZiY2M2NWJlZmI="); user_pref("browser.PICS.ratings_enabled", true); user_pref("browser.PICS.service.http___www_classify_org_safesurf_.SS__000", 9); user_pref("browser.PICS.service.http___www_classify_org_safesurf_.SS__001", 0); user_pref("browser.PICS.service.http___www_classify_org_safesurf_.SS__002", 0); user_pref("browser.PICS.service.http___www_classify_org_safesurf_.SS__003", 0); user_pref("browser.PICS.service.http___www_classify_org_safesurf_.SS__004", 0); user_pref("browser.PICS.service.http___www_classify_org_safesurf_.SS__005", 0); user_pref("browser.PICS.service.http___www_classify_org_safesurf_.SS__006", 0); user_pref("browser.PICS.service.http___www_classify_org_safesurf_.SS__007", 0); user_pref("browser.PICS.service.http___www_classify_org_safesurf_.SS__008", 0); user_pref("browser.PICS.service.http___www_classify_org_safesurf_.SS__009", 0); user_pref("browser.PICS.service.http___www_classify_org_safesurf_.SS__00A", 0); user_pref("browser.PICS.service.http___www_classify_org_safesurf_.service_enable d", false); user_pref("browser.PICS.service.http___www_rsac_org_ratingsv01_html.l", 1); user_pref("browser.PICS.service.http___www_rsac_org_ratingsv01_html.n", 4); user_pref("browser.PICS.service.http___www_rsac_org_ratingsv01_html.s", 3); user_pref("browser.PICS.service.http___www_rsac_org_ratingsv01_html.service_enab led", true); user_pref("browser.PICS.service.http___www_rsac_org_ratingsv01_html.v", 0);
Adding tarah to list. It looks like if we go out with this pics are broken in 4.06. Dozens of sites fail because when pics are turned on including the above sites and things like www.etrade.com. If we do ship like this and it is a client side problem then we should not allow users to us netwatch.
Can't duplicate this with the debug build! Still trying...
Well this is a good one and it affects all platforms but it can be kind of random. If the image is part of a page it shows up if it's by itself it does not. It occurs with both gifs and jpgs but not with all.. (seems like pics is trying to scan the gifs data as if it's html) You will be able to view the image if you make a second request for it. Enter the url for the image if it does display.. hit return then it will.
Short of switching off netwatch, there is really no quick fix for this. I know that our server handles the user agent to respond differently to the netwatch page. Maybe we should switch this off for 4.06 as well (just like it does for 4.05)
Given the fact that this isn't consistantly broken for all images, and there's a fairly simple workaround I think we should go out as is. Worst case we can decide on Monday to flip the switch on the server.
I should clarify, This is a bad bug because if you goto certain web servers like http://www.etrade.com and with pics turned on and you click on any of the links they will not work. They will keep you on the same page. Testcase: Turn picks on goto http://www.etrade.com click on the Account Benefits link on the left you stay on the same page click on the Investment Tools link you stay on the same page This happens on all of the sites listed above and there is no indication that pics is causing the problem so you would never be able to fix it.
I should clarify, This is a bad bug because if you goto certain web servers like http://www.etrade.com and with pics turned on and you click on any of the links they will not work. They will keep you on the same page. Testcase: Turn picks on goto http://www.etrade.com click on the Account Benefits link on the left you stay on the same page click on the Investment Tools link you stay on the same page This happens on all of the sites listed above and there is no indication that pics is causing the problem so you would never be able to fix it. i would recommend either fixing the bug or shutting down the pics webserver
Matt I tried this, but wasn't successful in duplicating the etrade page problems.
Gagzilla, you might try the optionslink or techfed.org example above - they are reproducible (at least for me). I couldn't duplicate the e*trade problem. I'm also updating the summary. Also had to change to P1 since P0 causes an error for some reason.
Jan -- setting this TFV to 4.5, letting you set the appropriate M build Paul -- assigning you as QA, please assign appropriate QA to verify on 4.5
Setting to 4.5b2.
Reviewed bug. Leaving as TFV 4.5b2.
I have changed the TFV for the browser/composer/java/etc bugs for which I had no response to my e-mail. The new TFV is M15. If you have a low risk fix in hand that can be reviewed an checked by 11:59 pm tonight, feel free to change TFV to B2. ---- marek
Nisheeth, hate to do this to you, but this looks like a major goof up inside javascript/layout again. Essentially what I have been able to figure out is that in laytags.c when we don't find any PICS information about a url, we try to retrieve its root url faking a javascript src tag. Now how convoluted could that be? Anyhow after we receive the root url, we should default to displaying the image properly, but we don't. I'll let you find out why....
We got to fix this one.
The PICS code in lo_PostLayoutTag() was not checking whether layout is blocked before calling into lo_ProcessScriptTag() to do the root url fetch of PICS rules. Fixed this. I also tried to make PICS redo the root url fetch once layout unblocked but that turned out to be a significant code change and I am not comfortable putting that in for 4.5. So, as things stand now, PICS rules at the root url will be ignored for the case when the first tag that begins the body of the HTML document is a tag that causes layout to block (<IMG> with no width or height or <LAYER>). For other cases, PICS should work like it used to.
qa assigned to ajohnson for verify
https://webbranch.techfed.com/ still doesn't load with pics enabled. Loads fine with pics turned off. The other two sites that were broken work now. Re-opening bug. Using 4.5 candidate build on win95.
Clearing resolution. Will not hold 4.5 RTM, moving to 4.51. But dp, should it be 5.0.
Accepting bug..
TFV to 5.0. Nisheeth, please close it if it doesn't pertain to the new architecture any longer.
Moved over from bugsplat 314034. I believe PICS is being completely re-written for 5.0. If this is the case, this bug may be invalid.
Setting all current Open Critical and Major to M3
Status: ASSIGNED → RESOLVED
Closed: 27 years ago
Resolution: --- → WONTFIX
Yes, marking this bug WONTFIX because PICS is being re-written from scratch for the new code base. Should I be marking this REMIND so that we can test the new PICS code once its done? I am not doing that because this is a pretty generic bug and should get covered by regular PICS testing. I'm leaving it to QA to make the call and change the resolution if you think it should be different. Thanks.
Status: RESOLVED → VERIFIED
This is fine. I have put it in my list of testcases. Marking verifed.
You need to log in before you can comment on or make changes to this bug.