Closed Bug 30547 Opened 25 years ago Closed 25 years ago

confusing security dialog pops up when running browser buster on www.benews.com

Categories

(Core :: JavaScript Engine, defect, P3)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: chofmann, Assigned: norrisboyd)

References

(
URL
)

Details

(Whiteboard: [PDT+] w/b minus on 03/10) 

running browser buster with win32 3/4 build..
http://komodo.mozilla.org/buster/test_url_25.html

it happend to cross www.benews.com and the following
dialog was popped...

javascript error: access disallowed from scripts at
http://www.benews.com to documents at another domain
URL: http://www.benews.com/  
Line number: 13

This error may indicate the site has not been updated
for mozilla.  Please contact the site adminstrator or
see http://developer.netscape.com/mozilla

  [ok]


what does this mean?
did the dialog get properly fired...  the benews.com 
domains are the same?

I tried just visiting the benews site directly and
it seemed to load fine without this dialog.  is
loading benews with the browser buster frame set
having an undisired effect?
adding ekrock to cc list....  what would a site admin do to 
correct the problem if seamonkey detect this condition.

are there plans for a more specific url than developer.netscape.com/mozilla ?

infact http://developer.netscape.com/mozilla  gets not found right now?
do we want to consider tweeking the UI a bit to point at
a live link that explains the problem for beta1?  

should this be a mozilla url since the problem might be
one for all mozilla browsers?

any ideas on how visible this dialog might be to 
users of beta1?

put on beta1 radar.
Keywords: beta1
Adding mccabe, who implemented the alert, to cc: for his thoughts.

Looks like two things are happening here:
1) site is triggering a JS security error
2) the new "show the http://developer.netscape.com/mozilla/ on JS error" code is 
as a result being executed

That URL is intended to be displayed until FCS for all pages that cause a JS 
error to guide folks to upgrade how-to info and encourage Nav4-only or IE-only 
sites to support Mozilla.

The referenced URL will not be live until sometime a bit after 3/21 most likely;  
some related pages that it will link to have to go up first. See 
http://client/seamonkey/launch/launch_plan.htm to understand the plan if you're 
Netscape internal. (Sorry, not making our launch plan public. ;-> )

BTW, if we're really concerned about that URL not being live until 3/21, we 
could as a temporary measure have the web site team redirect 
http://developer.netscape.com/mozilla/ to 
http://sites.netscape.net/ekrock/standards.html until then.
jeez, I didn't know that http://developer.netscape.com/mozilla/ wasn't going to 
be live for *weeks*. Eric, why not put *something* at that url now, even if it 
is just a page with a link to http://sites.netscape.net/ekrock/standards.html ?

Also, Just typing www.benews.com into the url bar does not give me a security 
error on my build. Is there an origin problem when running in the browser 
buster? Is this something that ought to be fixed? Norris?
Awright awright. ;-> I've requested a temporary redirect of 
http://developer.netscape.com/ to my standards page pending launch of the actual 
mozilla area content.

We can spend the rest of this bug report focusing on any security issues.
I now see that a newsgroup posting is directing those concerned about the error 
alert here, so here's my draft text for making the error alert a bit more 
specific if we want to. Comments?
---
This page caused a JavaScript error. If you visit this page with another browser 
such as Netscape Navigator 4 or Internet Explorer and don't see a similar error, 
it may indicate that the site has not yet been updated to support standards 
implemented by the Mozilla browser such as the W3C Document Object Model (DOM).  
Please see http://developer.netscape.com/mozilla/ for more information and use 
the email templates there to inform the site's adminstrator about this error
message. 
A good message is important (and it's zero-risk to pick a new one.)  I'd say the
shorter the better, though.  What's the minimum that still communicates the
situation clearly?

To be honest, I think my proposed text *is* the minimum that communicates the 
situation clearly. Drop any phrase and you're losing information. 

Suggestion: if anyone thinks they can edit my text down without losing 
significant info, please post your edit in this report for evaluation. Otherwise 
let's just go with my slightly-longer-but-complete wording in the interest of a 
message that truly informs rather than confuses the reader and also tells them 
the specific steps they should take.
I don't see the dialog with build 2000022708.

norris,  you will need a build later than friday.
I think that's when maccabe turned on the js error dialog.

we really need to back out the js error dialogs.
we pulled them from 4.06 because of the poor user 
experiance on an escalation that came all the way from marca.

mozilla -console is available for any site admin that wants
to see js errors.


Hmm--I can get error messages from this build, just didn't see it at the URI you 
posted.

FWIW, IE puts up dialog boxes when it detects JScript errors.
Putting on PDT+ radar for beta1.  Must fix by 03/10 please.
Whiteboard: [PDT+] w/b minus on 03/10
Brendan also weighed in and said that alerts are not the way to go.  ("Feh", he
says).

I've added a pref for showing alerts on errors, turned off by default.  Seems
like the conservative way to go.

I haven't yet checked this change in.


Eric - I've also changed the alert text after your suggestion.  I want to keep
the text as short as possible, so I dropped a few phrases from your suggested
text, in the anticipation that it's more flexible to point bug submitters to a
webpage we can change later than to hardcode it into the product.

The text is now

         "If you visit this page with another browser and don't see a similar "
         "error, it may indicate that the site has not yet been updated to "
         "support standards implemented by the Mozilla browser such as the "
         "W3C Document Object Model (DOM).  Please see "
         "http://developer.netsape.com/mozilla/ for more information.";

It's a tradeoff of minimizing interruption to ordinary users vs. maximizing 
pressure on sites and developers to upgrade--upgrades that will ultimately make 
Mozilla display more pages better.

Ultimately the JS error alerts will be replaced by the JS error 
console that we have now in 4.x. However, the JS error console won't make it for 
beta1. We need something else in the meantime to make users and developers aware 
of the need to upgrade a given page. The error alert is a logical 
temporary workaround.

The pref turned off makes this tool available for use by developers who know 
about it and is a conservative approach for beta1. But realistically, hardly 
anyone will use a default-off pref so the upgrade evangelism will be drastically 
reduced.

If memory serves, the reason JS alerts used to give a bad user experience is 
that you might get a separate alert for every JS error on a page (up to a 
certain point after which I think it gave up). Mike--will we get a maximum of 
one error alert per page load? 

If we will get one alert per individual JS error, this could be bad UE.

I'm not going to argue the point. If we'd thought of this a month ago, the best 
approach would have been to default it on in the dailies and see how it worked, 
then make a decision for beta1 based on that. But it's too late for that, so 
maybe we're safest not turning these on for beta1.
JS error alerts are now disabled unless the javascript.error.alerts pref is set.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I'm going to reopen this bug to make sure 
we understand what is going on with the specific 
error below, not the general bug of js error dialogs
cause useability problems.

javascript error: access disallowed from scripts at
http://www.benews.com to documents at another domain
URL: http://www.benews.com/  
Line number: 13

norris, the way to reproduce is to go to the test url
and then let the cycle come around to url 55 witch is
the benews.com site.  that will load the benews site 
in the browser buster frame and show the error if
you have a weekend build or the new pref turned on.
URL: http://komodo.mozilla.org/buster/test...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I've concocted a smaller test case at 
http://warp/u/norris/tests/mozilla/30547.html. This shows the error in both 4.72 
and in mozilla. 

The problem the line

if(top.thepage){r=top.thepage}else{r=top.document.referrer;}}

which attempts to access the containing frame's referrer field, which is a 
private property. 

Since the error is correct, closing out this bug as invalid.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → INVALID
http://developer.netscape.com/mozilla/ is still giving a page not found error.
That makes that alert message "really really" helpful. Netscape telling people 
they should have their pages fixed for the new browser while showing itself 
unable to set up content for and about the new browser.
Works for Me
Platform: PC
OS: Windows 98
Build # 2000100508 M18 Trunk Build
Marking as Verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.