New Forums

I tried checking out the new forums today, and I wasn't able to log in. I didn't get any error message, it just wouldn't respond when I tried selecting log in.

I am using Internet Explorer Mobile on a Windows Mobile 5 based T-Mobile Dash. The current site works fine, and on the new one I can enter my email address and password, but when I highlight the log in button and try selecting it, nothing happens.

Not sure what to tell you. I don't have a mobile install to test on. I find it hard to imagine that Microsoft's own button controls wouldn't work on their own browser. It's the same login button used on this site.

It looks almost faded out, as if it's in a pressed state, so when I select it, it's not "finishing" the click.

Also on a side note, the register button suffers the same fate on my device (I tried creating an account there just to test).

I'll see if I can try it tonight at work to see if the buttons look any different on a PC...

and that's kinda weird if they're the same buttons, because the ones here on the old version work fine.

Sounds like the browser is losing it's "focus"...so it doesn't know when/where your mouse-click is happening...

It caused us some intermittent grief on implementation of our latest system upgrade, sounds *vaguely* similar...just a thought.

The changing look is just a CSS hover trick. It's a hyperlink, not a button. It just looks like one.

I was thinking about the focus, gator, except it still has the button surrounded (as in that's the link that has the focus)

The weird part that stumps me is that in the mobile browser, once a particular hyperlink has the focus it keeps the focus until you scroll to another one, even if it's not visible on the actual screen (so if you scroll down without finding a link and press the select key, normally it will STILL follow the link that last had the focus, be it a standard anchor tag in html or a form submit button) This just sits there. No indication of a selected link, no error message... nothing.

As for the css trick... I understand what you're referring to that it's not actually clicked... but on my device it has the "moused over" look all the time - regardless if the focus is on the button or another control (like the text box next to it). I'm wondering if your CSS implementation differs from cbuzz, and if so I'm thinking it might interfere with the mobile IE and how it's rendering the buttons in some way.

CSS has nothing to do with whether or not something is clickable (save for if it's simple hidden from view). It's totally a presentation technology.

On a regular PC, yes. However the CSS code could be interfering with the hyperlink in the mobile browser.

I know you're probably going to discount it as a possibility, but it seems to be the only difference between the coasterbuzz login that works for me, and the beta login which doesn't.

You know, and this is not related to CSS, but in Safari for my Mac, I've never been able to log in. I do use Firefox for posting, but I didn't know if this was something limited to me, or if others are experienced this.

Actually, I *think* I've found the culprit.

And if I'm right about this, then you were right about the CSS not interfering, Jeff.

I finally got to a computer and did a little looking at the html code from the not-logged-in version of both pages, and found out that there's another *HUGE* difference in the logins between the 2 sites:

On Coasterbuzz, the login graphic is actually a form submit button, so when I "click" on it, I'm just submitting a form and the server processes the information like a standard HTML page would without any sort of DB or extended programming. One doesn't even need a database to have a form in that manner (although obviously in this case for loggin in, one would need to grab the login information from somewhere. :) )

On the beta, as you said, it's just a hyperlink. The snafu comes in that the source for the hyperlink is a javascript reference to an intrisic function you wrote to handle it. From what I can gather, it doesn't use a form submit at all (unless that function forces a form submit without further user interaction since they already clicked the link to start the process rolling).

My next task is to doublecheck whether or not (and to what extent) the mobile Internet Explorer for Windows Mobile 5 is compatible with javascript. As I tell most of the customers that call in to me when one specific site won't display, "some sites use extended programming that may not be compatible with the mobile browser. There may be a 3rd-party software available that may allow it, but it's not supported directly through T-Mobile. Your best bet would be to contact the website administrator and see if there's a mobile-capable version of that page available."

...I'm glad I do that stuff for a living - it gives me a lot more resources to check! :)

P.S. Failing that, Jeff, is there any possible way you'd be able to make a mobile-capable version of the login/register pages designed with a form submit rather than javascript hyperlink? It would only need to be the login page -- cookies work fine, so once I chose 'save login', I wouldn't have any problems with the rest of the site. (As it is, I can still navigate the site just fine on my Dash.. I just can't log in or register) I realize the answer would probably be no for the beta, but something to consider for the full release, and I would be very happy to test it for you and make sure it's working :)

The link is, cleverly enough, called a LinkButton in ASP.NET, and as far as the user is concerned, is just like pressing a button. There's a basic script that is called from various events on a page (including link button clicks) called __doPostBack(eventTarget, eventArgument) that submits the form. In this case it just sends the button's name, but some controls also send other data. The submits on the replies work the same way, and have for more than three years.

No way am I going to change that arrangement, because it works in every other browser, and it's more flexible for a lot of reasons. I'll screw around with the emulator if I have time, but it's not a priority.

As for Sarari, I'll check on that later, but I know people that have been using it for years on this site.

just a npte if you decide to try in an emulator, this isn't a wap browser so wapsilon won't give accurate results. It's a mobile version of internet explorer (complete with the familiar blue 'e' icon)

Thanks for the information. I'll do some more research an keep you up to date on my progress in case it comes up with someone else. If worse comes to worse I'll try logging in on a PC and copying the cookie to my mobile device

There is an emulator somewhere in the Visual Studio install package... I just don't know that I want to mess with installing it.

Ryan, I've had issues with Safari off and on. Sometimes when I log in, I get an error message, something like "The object has been moved..." But then all I have to do is reload the page and it shows me as logged in. :)

I doublechecked, and mobile IE does indeed support Javascript (I could have sworn it did, but I wanted to doublecheck).

As for why the button isn't working.. I just re-read your other post, and noticed you said that the submit on the replies are coded the same way. Obviously, those work well because (with the exception of this post I'm making now) all other posts in this topic and for the past month or so were completely and totally on my Dash.

That makes it particularly puzzling as to why it works here, but not there.

I mean no disrespect, but is there a semi-colon or some other very very minor typo somewhere that the "big browsers" are overlooking that is causing the mobile browser to snag when processing the function call? Is there anything else, however trivial it may seem to you, that is different between the implementation of the replies-submit and the implementation on the login of the beta that may be causing it? maybe a hard-coded URL reference somewhere or even where the handler appears in relation to other html tags? (just trying to think of possible errors that I myself have made in my web authoring past that took days to find what I did wrong)

Actually, I think I may have found it. I don't know enough about how your site is coded to know if this is going to be changeable. As I was writing this reply, I took another look at the code from this page (which works) and the beta page (which doesn't work), and pasted them into a text document side-by-side to compare, and have the following observation (edited for brevity and comparison purposes, working code first):

--------------------

function __doPostBack(eventTarget, eventArgument) {
var theform;
[if statement to handle a condition that could be different based on the browser]
[stuff to actually handle the request]
}

--------------------

var theForm = document.forms['aspnetForm'];
[if statement to handle a condition that could be different based on the browser]
function __doPostBack(eventTarget, eventArgument) {
[stuff to actually handle the request]
}

--------------------

Items of note is that within the first (working) example, the variable declaration is within the function definition. The second, although it's still within a javascript tag, it's not explicitly defined within the definition. Instead, it is defined (along with error catching based on browser version to make the rest work) outside of the function. So, my thinking now is that either the variable definition and/or error catching if statement is not being processed when the rest of the function is called (using a mouse click), which is causing it to basically stare at me when I click, instead of submitting the form. Would it be possible to encapsulate those definitions inside the function, or is it not possible based on the rest of your programming?

This could be an issue because of the relatively limited memory of mobile devices and mobile IE trying to conserve memory (almost like in the old days of DOS :) )

I don't write that script... it's part of ASP.NET. Someone in Redmond wrote it. It's about the most basic piece of script you could write. Considering the magic they're doing right now with ASP.NET AJAX, I'd say they're spot on in terms of compatibility.

So there's no way to bring the variable declaration inside the function? That sucks... I'd be willing to bet that's the reason that mobile IE is choking.

No way... the variable stays in scope for the rest of the page. Run it in Firebug, you'll see it makes perfect sense. If it has page scope, it can be called by other goodies inserted into the page as well.

I understand that's how it's supposed to work, but it doesn't seem to be keeping it in scope for any javascript in the mobile browser.

Edit:
purely for testing purposes, can you temporarily put it back inside the function to see if that is indeed what's causing it? *** Edited 1/5/2007 9:36:50 PM UTC by dannerman***

It seems evident that your browser is broken, not the forums. You're basically asking Jeff to break the site for everyone else just to locate a bug on your end--shouldn't you just switch to another browser that can handle javascript properly? There are plenty of other mobile browsers out there, such as Opera (and, of course, there's always the option of having a life and doing something else when you're out other than surfing Coasterbuzz).