It would be the logical solution ;)
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial
This topic was marked solved by its starter, on March 16th, 2013, 01:40 AM
sb refresh does not update scrollbar
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
Nao
- Dadman with a boy
-
-
- Posts: 16,082
There is definitely a problem with the reloadSB function.
What it does is: delete the current SB, remove its DOM elements, then repopulate it from the original, then re-create it, then open it if it was opened before, or focus if it was focused before.
It executes so fast that you never get to see the DOM be modified, and open/focus states are correctly restored. It's just the closeAndUnbind function that never properly sets the event (even though it DOES get executed at this point...)
I'm currently reviewing all .sb calls, and it seems that it's never called when in the middle of an opened SB, which totally makes sense, so indeed it might be best not to reopen the SB after re-creating it.
While doing this review, I also discovered a horrible bug in Wedge... I did, in a few occasions, launch a !ask() request in DOM events. Which is TOTALLY what should be done. Unfortunately, the nature of alert/confirm events is that they stall the execution process until we return, then we get a boolean parameter we can give back to the event. Okay. But say/ask are functions that don't stop any execution, and for that reason I had to had a callback system to allow for use in DOM events. It works very well, but it seems like I forgot to convert a few calls... And because ask() will immediately return false in a DOM event, if you take action after an !ask (rather than an ask), it will be executed.
To make it short (my explanation really sucks): Wedge could no longer un-admin anyone, or make a membergroup invisible, because it would always request confirmation and immediately return to cancelling the action, whatever your decision. Eh.
Of course, I'm fixing that right now...
But it just goes to show how fixing one bug can lead to fixing another... :^^;:
Crap!
My 'bug' wasn't due to sbox.js itself... It was due to the fact that I was refreshing multiple select boxes at the same time. (i.e. $('select').sb()).
There's just a little bit of logic involved... Each select box, when it's opened, attaches a window event to react to a click outside of it. However, the next sbox being re-created will delete said window event... That's why I couldn't click the window to close the current box. Bugger.
I'm not sure what are the odds of this not working...
I did a version of sbox where the dropdown isn't re-created (it just stays closed). It saves 20 gzipped bytes. I don't know what is best right now...
PS: also, for similar reasons, and in ALL cases here, the scrollbar is no longer selectable after a .sb() refresh. This is due, once again, to a document-wide event not being re-created.
What it does is: delete the current SB, remove its DOM elements, then repopulate it from the original, then re-create it, then open it if it was opened before, or focus if it was focused before.
It executes so fast that you never get to see the DOM be modified, and open/focus states are correctly restored. It's just the closeAndUnbind function that never properly sets the event (even though it DOES get executed at this point...)
I'm currently reviewing all .sb calls, and it seems that it's never called when in the middle of an opened SB, which totally makes sense, so indeed it might be best not to reopen the SB after re-creating it.
While doing this review, I also discovered a horrible bug in Wedge... I did, in a few occasions, launch a !ask() request in DOM events. Which is TOTALLY what should be done. Unfortunately, the nature of alert/confirm events is that they stall the execution process until we return, then we get a boolean parameter we can give back to the event. Okay. But say/ask are functions that don't stop any execution, and for that reason I had to had a callback system to allow for use in DOM events. It works very well, but it seems like I forgot to convert a few calls... And because ask() will immediately return false in a DOM event, if you take action after an !ask (rather than an ask), it will be executed.
To make it short (my explanation really sucks): Wedge could no longer un-admin anyone, or make a membergroup invisible, because it would always request confirmation and immediately return to cancelling the action, whatever your decision. Eh.
Of course, I'm fixing that right now...
But it just goes to show how fixing one bug can lead to fixing another... :^^;:
Posted: February 12th, 2013, 11:22 AM
Crap!
My 'bug' wasn't due to sbox.js itself... It was due to the fact that I was refreshing multiple select boxes at the same time. (i.e. $('select').sb()).
There's just a little bit of logic involved... Each select box, when it's opened, attaches a window event to react to a click outside of it. However, the next sbox being re-created will delete said window event... That's why I couldn't click the window to close the current box. Bugger.
I'm not sure what are the odds of this not working...
I did a version of sbox where the dropdown isn't re-created (it just stays closed). It saves 20 gzipped bytes. I don't know what is best right now...
PS: also, for similar reasons, and in ALL cases here, the scrollbar is no longer selectable after a .sb() refresh. This is due, once again, to a document-wide event not being re-created.