Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

bobbabuoy

macrumors newbie
Original poster
Mar 19, 2004
8
0
Please forgive me for my ignorance. I am a relative newcomer to web programming and know almost nothing about the Mac OS. I write mostly in html/javascript/asp on a windows xp box.

I have some clients that are having a tough time viewing my site on Mac OS with IE 5.1.7 when I redirect to a frameset page (even though the initial home page, which they see just fine, is a frameset page). When they use their Safari browser they can view the site but then they are having trouble viewing the contents of my iframes.

I can't post the source code right now because I am away from my desk but does anyone recognize a theme here? If the source code is needed I can post that later.

Thanks a ton!
 
kingjr3 said:
Source code or a URL is needed if you want any assistance.

http://www.cclog2.com

The problem comes in if you try to log in. To log in, select 'Your School' from the team dropdown, select 'Both' from the gender dropdown, select 'Coach' from the role dropdown, leave the period dropdown as is and click 'Proceed to Login.'

You should be redirected to a page where you can enter the login data (username and password). Mac users get a blank screen.

Thanks!
 
I really don't know anything about forms, but I do know that the JavaScript message that tells me my resolution is too high needs to go. The site displays just fine on 1280x1024 and just angers me that it pops up. A designer should NEVER have to use something like that, as the site should always be designed for all people and monitor resolutions.
 
I just took a quick look, and at first glance I can't see why it even works when you say it does. I would hazard a guess that it's in the ASP code itself - nothing I see in the HTML that's presented should behave the way you indicate. The form's "action" just self-calls the page.

We can't really look at the back-end ASP code using the URL. :p
 
Thanks all for the input and advice. A couple of questions/comments:

1) Point taken on the pop-up concern. I will modify that so that it only comes up if the screen res is less than 1024/768 but I really don't think that people that are using the site at 800x600 are going to get the full impact and, while it is annoying I agree, I want to go on record with those people as saying so. I agree that the ideal situation is to have one interface that works for all but with some people still using 640x480 and others using something much larger, I don't know if that is practical.

2) I am cocerned that you 'can't see why it even works when you say it does,' Westside guy. Could you elaborate please? I am somewhat new at this but I thought it was pretty well-written.

3) I will post the source code when I get home so you can have a look at the asp.

4) Of course, the issue is that one person said it works fine and another isn't sure why it works at all. All I want to know is why it works for some and not for others. Puzzling!!

Thanks
 
bobbabuoy said:
Thanks all for the input and advice. A couple of questions/comments:

1) Point taken on the pop-up concern. I will modify that so that it only comes up if the screen res is less than 1024/768 but I really don't think that people that are using the site at 800x600 are going to get the full impact and, while it is annoying I agree, I want to go on record with those people as saying so. I agree that the ideal situation is to have one interface that works for all but with some people still using 640x480 and others using something much larger, I don't know if that is practical.

2) I am cocerned that you 'can't see why it even works when you say it does,' Westside guy. Could you elaborate please? I am somewhat new at this but I thought it was pretty well-written.

3) I will post the source code when I get home so you can have a look at the asp.

4) Of course, the issue is that one person said it works fine and another isn't sure why it works at all. All I want to know is why it works for some and not for others. Puzzling!!

Thanks

1) Is between you and the users.

2) I tested on 2 macs, one with Jaguar and one Panther. On both with Safari the form works fine. The iframe is suspect, but that's what happens with iframes. If you use them, expect problems. Sorry but they just don't work well from broswer to browser.

On the Jaguar (10.2.8) machine with IE 5.2.2 the form fails. It is something in your asp.net code. I don't have IE on the Panther machine, but I'm guessing it would still fail. Also the iframe doesn't work at all in IE whereas at least in Safari it kind of works.

3) Maybe someone here will debug it. I'll pass as asp gives me a headache. To many potential problems to look for.

4) Different people with different machines. But I'm not sure why it works on one and not the other -- b/c the problem is in the asp.net code. I could take an educated guess but I'm sick today and don't feel like it.

--

WAR IS PEACE
IGNORANCE IS STRENGTH
FREEDOM IS SLAVERY
 
bobbabuoy said:
2) I am cocerned that you 'can't see why it even works when you say it does,' Westside guy. Could you elaborate please? I am somewhat new at this but I thought it was pretty well-written.

Okay, sorry, I'll rephrase it.

I took a quick glance at the HTML of the page. I might've just missed it, but I couldn't see any HTML code that does the actual redirecting to the page(s) you specify - it looks to me like the page just calls itself (the form's "action" parameter is just the same page we're already on).

Assuming I'm correct on that, it means the redirection to the page you want is actually being handled by the ASP scripting code, rather than the HTML page code - and of course we can't see the server-side ASP code.

If this is right, then there's no real way for us to tell you why it's broken on a Mac because we can't see the code that implements the redirect.
 
When clicking the 'Proceed to Login' button, the form action 'calls itself", processes the code (which I believe it does just fine) and then redirects to an a 'redirect.asp' page where the following code is processed:
Code:
<body onload="javascript:document.getElementById('redirectForm').submit()">
<%If Request.QueryString("where") = "choose_team" Then%>
	<form action="../menu/home.asp?bodypageL=../menu/keypad.htm&bodypageR=../menu/choose_team.asp" id="redirectForm" method="post" target="mainFrame">
<%ElseIf Request.QueryString("where") = "welcome" Then %>
	<form action="../menu/home.asp?bodypageL=menu.asp&bodypageR=welcome.asp" id="redirectForm" method="post" target="mainFrame">
<%ElseIf Request.QueryString("where") = "admin" Then %>
	<form action="../menu/home.asp?bodypageL=menu.asp?role=coach&bodypageR=welcome.asp" id="redirectForm" method="post" target="Top">
<%Else%>
	<form action="../menu/home.asp?bodypageL=../login/empty_menu.htm&bodypageR=../login/login.asp" id="redirectForm" method="post" target="mainFrame">
<%End If%>
</form>

The problem, if it lies here, is in the 'Else' part since that is the code that is executed when redirected from the previous page. This code loads a frameset with two vertical frames: the left one is empty for now and the right one is the login page. This is where I believe the problem lies(?) but I can't find it.

Here is the code for the frameset page that is being called but not showing up in some cases:

Code:
<frameset cols="150,*">
<%
Response.Write("<frame name=menuFrame src=" & Request.QueryString("bodypageL") & " noresize framespacing=0 frameborder=0>")
Response.Write("<frame name=infoFrame src=" & Request.QueryString("bodypageR") & " noresize framespacing=0 frameborder=0>")
%>
</frameset>

Thanks!
 
It's been a while since I did any ASP scripting; but the first thing I always did when I had problems was check out what MS's Website had to say... this might apply:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;173317

Having said that: You're doing this in a rather complicated way. Since your page requires JavaScript to work anyway, you could just leave the "action" entry in your form tag off completely and define an "onClick" action for your submit button. That "onClick" entry could be a JavaScript function that sets the form action appropriately, and then submits it.

I imagine this page isn't high traffic, but it's always a good idea to avoid making your server do unnecessary processing. Pass it off to the client instead.
 
I understand that we want the client to do as much of the processing as possible but, understanding that this page is never seen by the user, how can I eliminate the action tag and replace it with an onclick event if the page is never clicked on (since it is never seen by the client)?

Also, I think I have narrowed down the problem. Tell me if you concur:

I know for sure that neither page referred to in the 'Else' clause is getting shown to the user. I would determine from that that the issue is in the <body onload=...>. Agreed? If so, do you see anything in that syntax that would cause a problem? Remember that it works in every scenario that I have found except when running IE from a Mac (works when running Safari).

Thanks. I really need to get this figured out!
 
Taking a quick glance at your form actions seems you are using POST with GET variables attached to the action URL? Stick with one form method and set hidden variables within the form accordingly. If you set the action to GET, the variables within the form will translate to the URL you want.

Ex.

<form action="../menu/home.asp?bodypageL=menu.asp&bodypageR=welcome.asp" id="redirectForm" method="post" target="mainFrame">

would become

<form action="../menu/home.asp" id="redirectForm" method="get" target="mainFrame">
<input type="hidden" name="bodypageL" value="menu.asp">
<input type="hidden" name="bodypageR" value="welcome.asp">

Edit:

Couldn't help but notice the java_script_: in your onload event. Pull that out, its no good (or you could replace with javascript: ) and not needed. NEVERMIND - its the stupid filter on this BB!!!

Good luck.
 
Also, keep in mind that some of these users using IE 5.1.7 are either using Classic through OS X or OS 8.x or 9.x. Not sure if that will cause issues or not.
 
bobbabuoy said:
I understand that we want the client to do as much of the processing as possible but, understanding that this page is never seen by the user, how can I eliminate the action tag and replace it with an onclick event if the page is never clicked on (since it is never seen by the client)?

I'm afraid you've totally lost me here. The page is a form - how is it that it is "never seen by the user"? If it's not seen by the user, why are you asking us for advice on why it doesn't work? :confused:

If you're actually doing something completely different, then any advice we give here may be totally inapplicable.
 
Its not "seen" becuase he submits a form using the onLoad event.

You do raise a good point that we are debugging something that we can't see.

Hopefully my suggestions cleared things up with the problems he was having, all of which could mostly be avoided by not using framesets.
 
kingjr3 said:
Its not "seen" becuase he submits a form using the onLoad event

I'm not following this line of reasoning either. :D

onLoad performs a JavaScript action as soon as a page is done loading. If one submits a form using onLoad, there will never be a chance to make a selection - the form itself is superfluous.

If what you/he are/is talking about is the second time around (after "submit" is pressed on the form, at which point this page currently calls itself), then it's not actually running counter to my original comment. It's silly to for the page to call itself on submission just for the purpose of then using ASP code to perform the redirect. The initial submit should just trigger a JavaScript which then sets the target according to the desired parameters. No server-based processing is needed at all. If a person has JavaScript disabled... well the form as-is would not work anyway since it already requires JavaScript.
 
I never said there was any method to this madness. It could more easily be accomplished using alternative methods, javascript comes to mind for the redirects.

Although there was mention of a login form, so I assumed (maybe incorrectly) that he was trying to authenticate a user against some data store and then redirect based on a users selection in the login form. The way hes trying is very convoluted.

So I say to you bobba, be clear and concise on what your are trying to accomplish accompanied by full source where applicable, provide error messages or unexpected results, and stop using framesets - they are more hassel than they are worth. Screenshots aren't a bad idea if you cannot find the words to describe your problem.
 
Clarification

Let me bring you all up to speed and maybe this will help you help me (and I thank you all a ton for all you have done-I am learning a great deal).

This mess grew out of the following problem:

My home page (http://www.cclog2.com) has nested framesets with the outer containing two horizontal frames (with the top containing the header) and the bottom containing the nested frameset consisting of two vertical frames (with the left containing the keypad on the home page and the menu after login).

I want to replace both of the vertical frames on submit on the homepage and again on login. Further, to demo the service a user can click on one of the two green links near the bottom of the home page and bypass the login page altogether.

So I did it the way I did it because of my inexperience and based on help I have gotten from forum posts like this. It was not an easy fix because I need to be able to change two frames from the following scenarios: from a link, from a form submit, and from an asp Redirect.

All was fine until a user (who had previously been doing just fine with it) who was using IE on his Mac started getting blank pages instead of the login screen.

If there is a cleaner way to do this using just client side scripting I am all ears. As I said earlier, I am relatively new at this. I am a high school math teacher/cross-country coach with some programming background that is trying to develop a service for my runners (and others) to record their training online in the off-season.

I will wait your next suggestion and, believe me I appreciate greatly what you people are doing!
 
I can't answer the part about the ASP redirect because really I'd need to see the whole thing - I used to do a lot of ASP coding, but my current job is on a Linux server so I'm an Apache/Perl guy now. But as far as the form goes, here is some partial code that might help.

Let's say in your page you've got a form tag like this:

Code:
<form name="foobar_form" method="post" enctype="multipart/form-data">

Note that I didn't define an action on purpose.

Then in the form you might have some selects or whatever, and a submit button (this is by no means complete code):

Code:
<select name="item1" id="item1">
  <option value="foo">foo!</option>
  <option value="bar">bar!</option>
</select>

<input type="text" name="item2" id="item2" size="20">

<input type="submit" value="Update this information" onClick="doStuff(); return false;">

Then you could, up in the head part of your page, have a script section that defines "doStuff":

Code:
<script language="JavaScript">
<!--

function doStuff()
  {
  if (document.getElementById("item1").value == "foo") {
    document.foobar_form.action = "./target_page_1.asp";
    }
  else {
    document.foobar_form.action = "./target_page_2.asp";
    }
  document.foobar_form.submit();
  }

// -->
</script>

I actually use code like this a lot to make sure a form has been completely filled out, for example - in that case there's no way to submit the form (since no action is defined by default) unless my script sees that there's a value set for every required form element.

You might notice that I'm sorta mixing and matching names and ids, basically because I'm too lazy to rewrite it. :D
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.