Browser Interface Development

[Wedge009]

Hello everyone.

I thought it would be a good idea to create a separate thread for browser issues to avoid confusion with specific game-related discussions.

Here's what I have at the moment in terms of outstanding issues relating to the browser interface:

• Gecko: Clicking an Orders button is okay, but selecting buttons within the Orders windows results in an unwanted scroll-to-top-left. I am using Firefox 7.0.1 at present.
• WebKit: Clicking and Orders button results in an unwanted scroll-to-top-left, but subsequent clicks on buttons within the Orders window are okay. I am using Chromium 15 at present.
• Trident: Strangely enough, there does not appear to be any issues relating to unwanted scrolling and the Orders window. I am using IE 8.

I have a feeling this might be JavaScript and not CSS related, in which case I probably won't be very helpful, but I am continuing to investigate this.

 

[Avacar]

Wedge, thanks for tackling this in an organized manner.

If it is javascript related, I can at least upgrade our libraries. We're still using jquery 1.4.4 and my modified jqueryUI 1.8.6. I should be able to do a drop-in replacement of jquery to the current 1.6.4. jqueryUI is up to 1.8.16. I suspect those are rather minor upgrades, mostly handling bug fixes and incorrect performance (and compliance with newer browsers/standards)... which may be exactly the kind of thing that would fix these issues. That said, for the jqueryUI upgrade I'll need to merge in my changes to make sure that dropdown menu keeps working properly on stacks, but I should be able to handle that in a straightforward manner.

Wedge, I'll wait on you to say you want me to go ahead on this, but the javascript library update shouldn't be too hard.

 

[Wedge009]

I was working under the assumption that the libraries were stable and the issues were within your code. But when reviewing the scripts, it all seems fairly simple and I can't find anything particular relating to window or scroll positioning.

Go ahead and try updating the libraries, Av. Also, players, please feel free to add your feedback to this and any other issues you encounter.

 

[Avacar]

I was working under the assumption that the libraries were stable and the issues were within your code.

I do only use the stable releases (barring that I have personally augmented one of them to get those selectmenu dropdowns working). That said, even the 'stable' ones do have bugs and continued compatibility issues. These releaes were stable....6 months ago when I last upgraded the libraries.

But when reviewing the scripts, it all seems fairly simple and I can't find anything particular relating to window or scroll positioning.

I never do any scrolling with respect to the windows at all (in fact the only scroll work I've ever done was this recent minimap work, which is on a fork you don't have code access to yet, and we know that this issue is on the main branch). As for positioning, if you check out the 'preengine' files, you should find passages that are in jquery and reference the creation of .dialog() classes... hmm... as I type this, I went to look at them and realized that even there, I don't explicitly position them at all. I guess in that sense, they either default to screen center, or we're just lucky? Looking at the jquery ui dialog options, they do have an explicit position option I could set... perhaps that may help?

Go ahead and try updating the libraries, Av. Also, players, please feel free to add your feedback to this and any other issues you encounter.

Okay will do, will post or edit here to let you know when it is done. (I'll be doing this only to the actual phase5 main branch, and leave the minimap version alone for now since that wasn't even a formalize branch/fork, and I'll just fold it in when we're ready)

 

[Avacar]

Okay the library upgrade is complete, and on the regular phase5 as well as on the svn.

I made a choice to not merge the improved selectmenu code into the jqueryui file this time. On the one hand, that makes it yet one more file that needs to be pulled down and cached locally. On the other, it means I'm not as liable to get my jqueryUI files confused, forget which ones I've manually augmented with the correct selectmenu plugin. It means in the future I can continue to just drop-in-place the upgraded jqueryUI files, while refereing to our own custom copy of the selectmenu independently. Less chance for errors, easier bug isolation!

That said, it doesn't appear to have fixed anything.

One easy fix could be to make the dialog boxes modal, but then you wouldn't be able to access the things behind them. Another would be to make them fixed-position, but then you couldn't drag them around. (I'm not sure how much of this you guys do, but when I was testing, I'd often want to have 2-3 popups open + the orders window)

 

[Wedge009]

As for positioning, if you check out the 'preengine' files, you should find passages that are in jquery and reference the creation of .dialog() classes... hmm... as I type this, I went to look at them and realized that even there, I don't explicitly position them at all. I guess in that sense, they either default to screen center, or we're just lucky? Looking at the jquery ui dialog options, they do have an explicit position option I could set... perhaps that may help?

I noticed the reference to the pre-engine stuff in the Orders' script's switch statement... I should probably have a close look at them, then. As for the position options, I haven't gone into the details of how the jquery library works, but I suspect anything being left to 'default' could be a bad thing and would explain why three different layout engines result in three different behaviours. Could try specifying some options and see what happens.

Less chance for errors, easier bug isolation!

Yes, I agree, good idea to keep things separate in that regard.

That said, it doesn't appear to have fixed anything.

Sadly, that is my conclusion as well.

One easy fix could be to make the dialog boxes modal, but then you wouldn't be able to access the things behind them.

Is there a reason for accessing things behind the Orders window? Checking the stats of other ships, perhaps? If there isn't a real reason for it, this could be a possible solution... although I suppose there is probably a good reason for keeping it modeless.

 

[Wedge009]

I wonder if our scrolling issues are specific to the Combat Phase. There are no buttons to click in the Orders window for End Phase, so I can't test the Firefox issue, but clicking Orders in Chromium no longer has the scrolling issue... but I don't know if that's because I bumped up to development version 16. Can anyone confirm if the scrolling is still happening with the current stable Chrome 14?

 

[Wedge009]

I hope you consider this an improvement, albeit a rather minor one: I turned the Account tab's links into buttons similar (though not exactly the same) to the buttons in the Turn Navigation tab. Having the Register and Sign In text run together, as it did previously, bothered me a little.

 

[Ironduke]

Hm, Register and Sign In are still appearing as text in both Phase 5 and Phase 5_1 for me. Or is there any other link you're using?
Also, Phase 5_1 now produces a scroll bar in the lower portion of my screen (see attached screenshot).

 

[Wedge009]

I only committed my changes to Subversion - it's up to Avacar to include the changes into his copy. If you want to have a look you can use my copy (the address is also in the screenshot I posted).

I don't have access to the 5.1 branch - I think Av is working on that independently. Is the scroll bar a bad thing? I would think having it available would be helpful, not detrimental.

 

[Avacar]

Interesting, Wedge... you made them into buttons using only css... normally that would be okay, but it would probably better if you did it using jquery. Want to give it a try? Just undo the css you added, reference the jquery ui button page, and then add the jquery in the appropriate place (likely near the bottom of the navigation.js will do)

Spoiler: all you need to do is give them either a common class, or give them each an id, and then add:

$(domselector).button();

In the meantime, I will put up your changes to the 'live' area on my next code update (likely after I fix whatever bug is going on with game 4).

 

[Ironduke]

Yep, the Register and Sign In buttons are now there...

And Wedge: I'm not saying scroll bars are bad. But this one in particular just doesn't know how to behave... I should be able to see the map on my whole screen, and then the usual scroll bar below and to the right. However, right now, that horizontal scroll bar is cutting off a good portion of my map.

 

[Wedge009]

Interesting, Wedge... you made them into buttons using only css... normally that would be okay, but it would probably better if you did it using jquery.

I had a look at the jquery stuff for the Turn Navigation tab, but it seemed overly complicated to me. It was easier and straightforward to just do it in plain CSS. On its own, that's the approach I would prefer... but I know the jquery stuff is already in use so for the sake of uniformity, I would have used that approach... if I knew how to do it in the first place.

I'll have a look at converting it to jquery if I have time. (I'm so tired, haven't had a proper weekend for a while.)

I can't really help you with the scroll bar, either way, Ironduke. I understand Phase 5.1 is experimental anyway.

Incidentally, I had a peek at the issues with IE9... that's some crazy-weird horrendous bars happening there. I shudder to think what Trident is doing, I don't think it's worth the effort trying to fix it.

 

[Ironduke]

Yeah, well, never mind the scroll bar. Usually, I'm still playing under the regular Phase 5 anyway. It was just something I noticed when playing around with your version...

 

[Wedge009]

I'll have a look at converting it to jquery if I have time.

It took quite a bit of trial-and-error, but I worked it out in the end. Committed to the repository and live on my directory on the web-site.

 

[Avacar]

It took quite a bit of trial-and-error, but I worked it out in the end. Committed to the repository and live on my directory on the web-site.

Looks good Wedge! Technically speaking, (looking at Revision 534: account_widget.php) the only thing you actually needed to do was take your line 194 and put it on line 180. The statement on line 37 means that the jquery code runs after the entire page has run, so your declaration doesn't need to appear after the links, nor does it need to be in an independent <script> tag. All that aside, I'm leaving it as-is, since it clearly does work.

 

[Chernikov]

Unsure what/if you changed between the first set of Game 5 Turn 2 orders I issued this morning and now, but the interface no longer jumps back to the left hand side when entering the order interface. Still jumps when entering a barrel roll order.

 

[Avacar]

Hmm. all of you should clear your cache in case the old jquery is still being kept. Otherwise it may take a few days to get that upgrade...

Also, state your browser and version when posting in this thread so we can always track what works where.

 

[Chernikov]

Sorry, Firefox 7.0.1

 

[Wedge009]

...the only thing you actually needed to do was take your line 194 and put it on line 180. The statement on line 37 means that the jquery code runs after the entire page has run...

I understood what ready() does. I placed the button call at about line 180 previously, but that only applied the change to the Register / Sign In text. The alternative was to apply the button call where I've put it, or duplicate it for the Sign Out situation. Did I make the right choice? I prefer to minimise code duplication.