In a page's domready event I'm setting an event listener for a button that sets a Background Sync event in a page on my website (when offline), but even if the service worker has been loaded already on previous page visits, this line of code never resolves the promise, its status stays "Pending" indefinitely.
navigator.serviceWorker.ready.then(function (sw) {
$('#elt').on('click', function () {
sw.sync.register('contact-form-submission');
Since I know the sync event won't need to be set until after a form is completed, I tried wrapping this code in a setTimeout() of 3 seconds, which worked! My question is why this might be, I haven't been able to find anyone else indicating the .ready event wouldn't be available when the page is first loaded. Insight appreciated.
Related
I have a MVC web database application where the records are basically documents with items.
Documents are locked, not items and they locked by code when the user looks in any of 4 or 5 different screens for any given document.
there is a 10 minute time out on the record locks. The user does not do anything with the record for 10 minutes and another can take the record. There is code that detects the lock was lost and taken by someone else. It works fine and is technically sound.
The workflow of the application relies on the lock being released when the user leaves the screen or closes the browser, or if they press the refresh button.
These are work fine on windows and android but not on ipad.
I understand there is no
beforeunload
on ios but I though there was
unload
or
pageHide
neither of these work.
Here is my code.
var isOnIOS = navigator.userAgent.match(/iPad/i)||
navigator.userAgent.match(/iPhone/i); var eventName = isOnIOS ?
"pageHide" : "beforeunload";
window.addEventListener(eventName, function (event) {
ReleaseRecordLock(); } );
This code works on all mentioned platforms except that the events don't fire on IOS.
It looks to me that this is deliberate on Apple's part so I an not thinking it will change.
So now the question.
What can I do to ensure that these records get unlocked if a user changes screens or closes the browser. If they don't no users will be able to access the document for 10 minutes which will not be acceptable.
Thanks
Edit... I don't need pop ups or notification. I just need reliable unlocking
As mentioned above none of the events that are supposed to work actually fire. pageHide and unload do nothing.
I found mentions of how to get around this problem but no details so I though I would detail it here.
This solutions works with areas and standard sites.
My solution to get around part of this was to detect if the browser is running on IOS and if so to change the link in the menu.
<li>
#{
if(Request.UserAgent.Contains("iPad") || Request.UserAgent.Contains("iPhone"))
{
<a onclick="IOSReleaseLock('controller', 'action')" href="javascript:void(0);">LinkText</a>
}
else
{
#Html.ActionLink("link Text","action","controller",new { Area = "Tasks" },null);
}
}
</li>
Every single link in the application has to have a function called IOSReleaseLock() available or the solution will not work. Not all pages lock records, only those that actually change documents. Reports, and basic website functions such as change password, log out, and the sys admin stuff do not need record locks.
At this point I have 2 versions of IOSReleaseLock()
This is the version that is used on pages that do not required unlocking.
function IOSReleaseLock(_controller, _action)
{
var url = '/__controller__/__action__/';
url = url.replace('__controller__', _controller);
url = url.replace('__action__', _action);
window.location.href = url;
}
This is the version that is placed on pages that required unlocking.
function IOSReleaseLock(_controller, _action )
{
var url = '/__controller__/__action__/';
url = url.replace('__controller__', _controller);
url = url.replace('__action__', _action);
UnloadingRecordLockRelease();
window.location.href = url;
}
Every link has a wrapper so every single page must load a version of IOSReleaseLock(). This includes your /home/index or where ever your application starts. If you miss one then once you are on that page your menu system links will not work anymore.
Pages that require the UnloadingRecordLockRelease() function load that version and the pages that do not require unlocking load the first version.
On IOS every time you click a link, IOSReleaseLock() is called. This may seem to be obvious, but for clarity, the version of IOSReleaseLock() that executes is the version that is on the current page, not the version on the page you are going to.
So as long as the user stays on the site and does not close the browser then the records are unlocked correctly.
When the user logs out all records are unlocked but I have no solution for when the browser tab is closed or when the browser is closed without the user logging out.
I am getting Issue
unable to get property'_focusTabbable'of undefined or null reference
I am using Jquery-ui-1.10.2.custom.js
Here I am getting issue in
if ( !$.ui.dialog.overlayInstances ) {
// Prevent use of anchors and inputs.
// We use a delay in case the overlay is created from an
// event that we're going to be cancelling. (#2804)
this._delay(function() {
// Handle .dialog().dialog("close") (#4065)
if ( $.ui.dialog.overlayInstances ) {
this.document.bind( "focusin.dialog", function( event ) {
if ( !that._allowInteraction( event ) ) {
event.preventDefault();
**$(".ui-dialog:visible:last .ui-dialog-content")
.data( widgetFullName )._focusTabbable();**
}
});
}
});
}
This bug arises when you open a dialog and then, in an action button of this dialog, call a method that opens a second dialog. When you attempt to close the second dialog, the bug appears.
To prevent this from happening, close the first dialog immediately, and then call the second dialog.
$('#dialog1').dialog({
buttons: {
'No': function () {
$(this).dialog('close')
},
'Yes': function () {
// This works
$(this).dialog('close');
// Open second dialog
OpenSecondDialog()
// This doesn't work. A bug will arise when attempting to close the second dialog
$(this).dialog('close');
}
}
});
I'm opening one dialog and then another to confirm changes which were done in the first dialog. When confirming it doesn't close the first dialog which was opened. So I'm just destroying everything to get rid of the focus issue.
$(".ui-dialog-content").dialog('destroy');
I just put this one in the confirm function of the last dialog so it destroys all my dialogs (since they have the same class).
Just for future reference (and in case anyone else experiences this problem), I got the same error in jQuery UI 1.10.3 when re-opening a dialog after partial postbacks in asp.net. I found out that this was due to a variable $.ui.dialog.overlayInstances that is supposed to evaluate to 1 before the dialog is closed. Since every time the dialog is opened the variable is increased by 1, when the user pressed the close button my value often evaluated to 2 or more. My solution was to reset $.ui.dialog.overlayInstances to 1 every time I opened the dialog. So:
$("#myDiv").dialog("open");
$.ui.dialog.overlayInstances = 1;
I was working jquery-ui-1.12.1 and encountered the same error and as Emyr pointed out this bug has been fixed.
My first workaround used George Beiers approach. Close dialog1 before creating dialog2, then I would restore dialog1 after closing dialog2. The result didn't look so well but it cleared the error in every browser except Internet Explorer.
Turns out there was a function that was attempting to closed my dialog1(already closed) before closing dialog2. Once I reordered the code I was able to keep dialog1 open while I displayed dialog2.
My suggestion if you are having trouble fixing this issue is to add a console log message on the beforeClose and open events to keep an eye for odd behavior.
I remember that error.
For me was
I tried to open a modal by code, then I opened other modal also by code...
They opened well... but if tried again, I received that error.
I had to close the first modal before open a new one.
Two absolute beginner questions.
I have working code in my main.js enterState.
enterState: function(context) {
..
//keepAlive
var now = SC.DateTime.create();
if (now.get('hour') < 18){
SC.info ("main_state:enterState:go %#", now.get('hour'));
this.timer = SC.Timer.schedule({
target: this,
action: '_timerFired',
interval: 5000,
repeats: YES
});
} else {
SC.info ("MainState:enterState:nogo %#", now.get('hour'));
};
..
this.mainPane.append();
},
_timerFired: function(){
SC.info ("_timerFired %#", Date.now());
},
exitState: function() {
SC.info('main_state:exitState');
this.timer.invalidate();
this.mainPane.remove();
},
Question 1: the enterState is used every time a user goes to the main view, is the timer schedule initialized once or every time a user switches views?
Question 2: I think I need a query. e.q. the logged in username, to prevent an automatic logout due to the expired session MaxInactiveInterval. Is there sample code to get the spring username in the _timerFired function?
I saw the answer/solution of Maurits, thanks, but it is too complicated for me.
This timer will be scheduled every time this state is being entered. If this is the root state of the application, that will be once. If this state is used to display the mainPane and you are leaving this state somehow, and returning, then this timer will be initialized every time you enter this state.
You could keep the username as property of the current state (this._username) and as _timerFired is called with this being the current state (SC.Timer will take care of that through the target) you will have access to it. You'd need to set it somehow of course. Another solution is to read it directly from the controller you use for the login procedure.
Nevertheless, this solution is prone to trouble. The main reason for this is that you are creating implicit states. I mean that being authenticated is an application state, and instead of making this explicit through the state chart, you hide it within one of the states. As I wrote in the comment: I came to the solution I posted in the other question because of trying many different solutions and hitting trouble. What I learned from those issues is that the statechart is your friend, and really trying to work with it will help you avoid loads of headaches!
I have a wxLua Gui app that has a "Run" button. Depending on selected options, Run can take a long time, so I would like to implement a "Cancel" button/feature. But it looks like everything in wxLua is working on one Gui thread, and once you hit Run, pressing Cancel does nothing, the Run always goes to completion.
Cancel basically sets a variable to true, and the running process regularly checks that variable. But the Cancel button press event never happens while Running.
I have never used co-routines; if the Run process regularly yields to a "Cancel check" process, will the Cancel event happen then?
Or is there another way?
(the following assumes that by "Run" you mean a long running operation in the same process and not running an external process using wxExecute or wxProcess.)
"Cancel" event is not triggered because by executing your Run logic you have not given a chance to the UI to handle the click event.
To avoid blocking the UI you need to do something like this. When you click Run button create a co-routine around the function you want to run:
coro = coroutine.create(myLongRunningFunction)
Your Run event is completed at this point. Then in EVT_IDLE event you will be resuming this coroutine as long as it's not complete. It will look something like this:
if coro then -- only if there is a coroutine to work on
local ok, res = coroutine.resume(coro, additional, parameters)
-- your function either yielded or returned
-- you may check ok to see if there was an error
-- res can tell you how far you are in the process
-- coro can return multiple values (just give them as parameters to yield)
if coroutine.status(coro) == 'dead' then -- finished or stopped with error
coro = nil
-- do whatever you need to do knowing the process is completed
end
end
You will probably need to request more IDLE event for as long as your process is not finished as some operating systems will not trigger IDLE events unless there is some other event triggered. Assuming your handler has event parameter, you can do event:RequestMore(true) to ask for more IDLE events (RequestMore).
Your long-running process will need to call coroutine.yield() at the right time (not too short as you will be wasting time to switch back and forth and not too long for users to notice delays in the UI); you probably need to experiment with this, but something timer-based with 100ms or so between calls may work.
You can check for Cancel values either in your IDLE event handler or in the long-running function as you do now. The logic I described will give your application UI a chance to process Cancel event as you expect.
I don't use WXWidgets, but the way I implement cancel buttons in my lua scripts which use IUP is to have a cancel flag, which is set when the button is pressed and the progress display is checked for during the run.
Usage is like this
ProgressDisplay.Start('This is my progress box',100)
for i=1,100 do
ProgressDisplay.SetMessage(i.." %")
fhSleep(50,40) -- Emulate performing the task
ProgressDisplay.Step(1)
if ProgressDisplay.Cancel() then
break
end
end
ProgressDisplay.Reset()
ProgressDisplay.Close()
If you want to see the definition for the ProgressDisplay see:
http://www.fhug.org.uk/wiki/doku.php?id=plugins:code_snippets:progress_bar
I have a notifications setup which perodically retrieves notifications from a database via an AJAX call.
If notifications are new, then I want to add a jQuery UI "highlight" effect to the notification containing element.
There are lots of these for different notification types.
as the notifications are loaded in, the elements containing the notification data is giving a new class "flashAlert" where required. The function below is then triggered.
function startAlert() { // this function makes alerts flash
setInterval(function () {
$('.flashAlert').effect("highlight", {}, 2500);
}, 2500);
};
This works, however, if the class "flashAlert" is removed from the element (done by a 'clear notifications' function), the effect is still applied.
I know that I could call clearInterval in my "clear notifications" function, but then I have to set up a separate Interval function for every notification rather than a single function like this.
I've seen other questions on here with users finding difficulties having the effect working on elements which are added by jQuery, but nothing about removing the effect!
Doing a page reload clears it, but that's not what I want!
function startAlert(){
$('.flashAlert').effect("highlight", {}, 2500, startAlert);
}
And when you want it to stop in your clear notifications, simply do:
$('.flashAlert').removeClass("flashalert").stop();