When I started create extension, I didn't know that "popup" always reinit after open.
Is it have some options for off this behavior?
"background" page is not good for me.
That is the default behavior, just like closing-opening a tab/window.
Using background page (persistent: true) is a good way, it lives through the entire browser lifetime.
However, if for some reason you are not planning to use background page, I guess chrome.storage or Window.localStorage is also a good way, taking the former for example, you can store data through chrome.storage.local.set while retrieving the data via chrome.storage.local.get every time the popup page opens.
Related
I need to store some data every time I move to some other tab in the same window or some other window using chrome storage API or even when a new tab is created. So, basically when my active tab is no longer active anymore.
So, for example, If I am on tab A and then I move to tab B(or create a new tab). When this switching happens from A to B, I need to save data from the website running in tab A. (I am getting the data from the site in tab A using content script.)
A more concrete example would be, suppose I am on YOutube site and I have a timeout timer running(using a content script). So when I move to some other site I want to stop the time get the current remaining time and save that. and if the other site is youtube too(in tab B) I would start the time from the previously saved value.
Is there any event listener for this? I looked at the documentation for chrome.tabs but could not figure it out.
I saw onActivated event listener but I am not sure if that would be useful.
Or is there some other way to achieve this?
Yes, according to the documentation onActivated:
Fires when the active tab in a window changes.
As an alternative, also can use content scripts that notify your extension when a page gain or loses focus with window.onfocus and window.onblur.
This way you'll be able to track the visibility of the tabs, though you should carefully select the required permission.
I have a strange thing occurring; as usual, I can't post code, unfortunately, so I'm describing the problem in case anyone can suggest a possible cause.
I have an xpage with a custom control included on it; the custom control handles document locking and changing to edit/read-only modes via links. The document locking is done by setting an applicationScope variable based on the UNID. To make it more friendly for other users on the system, I run a function periodically on the page to check whether the document is locked or not and update a link/label/tooltips appropriately (e.g. if locked by another user, then the "Edit" button is disabled; when the lock is released, it's re-enabled). This is done by calling an "xagent" through a standard, simple dojo-based ajax call.
For some reason, the behavior of the system gets erratic after 45 seconds to a minute. I'm checking the lock status every ten seconds or so, so it's not happening with the first call. I'm displaying a list of records associated with the document; each record is a row in a repeat. When I first go into edit mode, the controls are all displayed as they should be, i.e. editable. If the user changes a particular value with a combobox, it updates the whole row with a partial refresh. When things get erratic, I noticed that the row starts refreshing in read-only mode, which suggests to me that the document is changing edit mode. The only time I knowingly change edit mode is if a "Cancel" or "Save" button is pressed. (The locking mechanism itself doesn't have anything to do with the edit mode.)
It certainly seems like the ajax call I'm making is at the root of this. But I've stripped the xagent and the client-side code down to practically nothing, and it's still happening. I can't see what would be causing this behavior. Can anyone hazard a guess? Thanks....
Maybe check if the server log file has warnings like:
WARNING CLFAD####W: State data not available for /page because no control tree was found in the cache.
If you're seeing those warnings, it could be that the server can no longer find the current XPage page instance in the cache. In that case the page will revert to the initial state, like when the page was first opened. That might be why the document goes to read-only mode.
The session cache of server-side page instances only holds 4 pages when xsp.persistence.mode=basic, or it holds 16 instances when xsp.persistence.mode=file or fileex.
If you load 4 xagent page instances, then that will fill the cache, and it will no longer be able to find the page instance for the current XPage you are viewing. So the XPage will stop performing server-side actions, and partial refresh will always show the initial state of that area of the page.
To avoid that problem, in the xagent page you can set viewState="nostate" on the xp:view tag, so that page instances are not saved for the xagent page, as described here:
https://tobysamples.wordpress.com/2014/12/11/no-state-no-problem/
Or else you can create and reuse one page instance for the xagent, so only one is created. That is, on the first call to the XAgent, have the xagent return the $$viewid value for the xagent page instance (#{javascript:view.getUniqueViewId()}), and then in subsequent requests to the xagent use that $$viewid in the request, to restore the existing xagent page instance instead of creating new instances that will fill the cache. So the subsequent xagent requests will be like so:
/myApp.nsf/xagent1.xsp?$$viewid=!aaaaaaaa!
It's hard to troubleshoot without code, but here are a few thoughts:
How are you checking document locking? Via a client-side JavaScript AJAX call or an XPages partial refresh? If the latter, what is the refresh area? If the former, what is the refresh area you're passing and the return HTML? Does it always occur when you're in edit mode on a row and the check happens, or independently of that? The key thing to check here is what the check for locking is doing - is it checking the server and returning a message outside the repeat, or checking the server and returning HTML that overwrites what's currently on the browser with defaults, e.g. the document mode as read mode.
What network activity is happening between the browser and the server and when? Is something else overwriting the HTML for the row, so resetting the row to read mode.
It's unlikely to be random, the key is going to be identifying the reproduceable steps to identify a common scenario/scenarios and cause.
EDIT
Following on from your additional info, is there a rendered property on the Edit link? If that calculates to false in earlier JSF lifecycle phases, the eventHandler is not available to be triggered during the Invoke Application phase. Because the eventHandler also includes the refreshId, there is no refreshId and refreshMode, so it defaults to a full refresh with no SSJS running. See this blog post for clarification http://www.intec.co.uk/view-isrenderingphase-and-buttons/.
My extension runs on an existing web page I do not control. I want to have an options page for it. What I haven’t figured out is how to get the option values from the injected code. localStorage isn’t shared, of course. I’ve tried using sendRequest / addListener in both directions, although it would be much preferable to push values from the options page to the injected code than they other way ‘round.
At the beginning, I simply put the option checkboxes on the manipulated page (the one the code is injected into), and those checkboxes set values in localStorage:
localStorage.showStuff = !!$(evt.target).attr(‘checked’);
Then I check those values in the code:
if (localStorage.showStuff == ‘true’) { … }
I moved the checkbox code to the options page and had it do a sendRequest when the options changed, and had my injected code have a listener for the message, but it doesn’t get the messages (my background page does, but that doesn’t help me). I also tried having the injected code hand a callback to the options page, but the sendResponse object only seems to work for the duration of the notify handler (not surprising, but I had to give it a try).
Right now my manifest’s permissions lists the foreign page ("http://example.com/*") and “tab”.
The one thing I know I can do is asynchronously query the options page via a callback, but the code doesn’t (and really can’t) work asynchronously without serious rewriting.
Any and all ideas welcome, thanks in advance.
i'm new to chrome extensions but when i tried to write/read localstorage from both, background script and option page it worked perfectly.
i haven't tried native localstorage but chrome's storage api.
take a look at this
code A: (set)
chrome.storage.sync.set({'key':'qwe'});
code B: (get)
chrome.storage.sync.get('key', function(response) {
console.log(response); // 'qwe'
});
u could put either code A in the background and code B in the option page or the other way around.
they are using the same storage.
this works for me. i hope u'll get there too.
The thing to remember is that only the background page is long-lived. The rest of the pieces of your chrome extension are transient (content scripts for the duration of the site navigation, options pages only while open, etc).
So you have to use messaging and save things using the background page. However, get ready for the storage API which should be landing soon. This will make things a lot easier for you!
Check it out here.
I have a search dialog that I am popping up and filling with jquery templates. After they make a selection I set a value on the current page. As such I don't need hashTags or anything like that, I just need a pop-up dialog that I can open and close programatically. I am currently opening the dialog with
$.mobile.changePage(dialog, { transition: "slide", changeHash: false });
and closing it with
dialog.dialog('close');
However, in certain cases (when the page is navigated to), closing the dialog refreshes the current page.
Is there a better way to interact with this?
Update:
I think I figured out what is going on. So for some reason, jquery mobile usually keeps 2 pages loaded on the DOM - one of which is invisible, you can verify this by running $('[data-role=page]') in the console. One page is the page you're on, the other is the page that you initially navigated to. Not quite sure why they choose to do that, but there you have it.
So they treat dialogs as a page navigation with a different transition even if the dialog is already in the DOM. Therefore, if you go directly to the page and then trigger a dialog, modifying the current page and closing it works fine - because the original page is always loaded in the DOM. However if you go to another page, than navigate to the page that triggers the dialog, and THEN trigger the dialog it destroys the current page so that the pages in the DOM are the initial one and the dialog. In that case it reloads that dialog-launching page entirely and you never get a chance to make any modifications.
Jeez. How do I interact with the jqm dialog widget directly?
You can try two other things. Both should work:
1 set DomChache
How about overriding JQM to keep the page your are firing the dialog from in the DOM? The docs say you can set data-dom-chache and override cleaning the page from the DOM.
If it only happens when you load this page in via AJAX (vs. loading it directly) you could make DOM-keeping dependend on your trigger page having data-page-external, assign DOM-chache="true" only when the dialog is openend and remove it again once the dialog is closed.
2 override JQM
I had the same problem you described and got it to work like this (requires hacking into JQM though...):
// inside transitionPages function
if ( !$(toPage).jqmData('internal-page')
{fromPage.data( "page" )._trigger( "hide", null, { nextPage: toPage } );}
}
My problem was that pagechanging to certain pages (same as dialog) caused the preceding page (where the dialog fired from) to be removed from the DOM, so I had a blank screen (when trying to go back). I added data-internal-page="true" to the pages, which should keep the preceding page intact and added the if-clause in JQM.
So now pageHide (and DOMcleanup) only fires, if I'm not going to a page labelled with data-internal-page="true"
Cheers!
I think I was having a similar problem. What I wanted to do was based on certain parameters, pop a dialog window on load (with that content on the same page), which they can close and view the page that loaded.
I could get it to pop on load using load, or the pageshow events, but when I clicked close that sent you back to the previous page in history, instead of just closing the dialog.
//target your 1st page content, here its id=success
//the modal content is in a page id=dialog and data-role="dialog"
$('#success').live('pageshow',function(){
window.setTimeout(function(){
$.mobile.changePage('#dialog','pop',false,false);
},1);
}
Its a hack, and just allows the page load to beat the dialog so it gets stuck in history. Then the default dialog close behavior for the dialog works as expected. Talk about a PITA, if they took a little more for the JQuery UI dialog it would have made things a ton easier.
And regarding your question: Have you looked at Jquery Mobile Actionsheet plugin
If you don't really require a page to be loaded, that should be ok.
Also helpful could be Cagintranet iPad popover, although you have to tweak the design to be fullscreen on mobile devices. If you require CSS/Jquery to do that let me know (I'm using this in a JQM plugin I'm writing)
Hope that helps.
I want a confirmation window on click of a browser back button. If I press yes then the previous page will get load ortherwise I will remain in the same page?
Any suggestion is highly appreciated.. But please be on track.. my question is straight forward
thx in advance..
Why do you want to do that?
You can prevent them from leaving the page by using Javascript, but if you can't use that, it's not possible to do anything about it.
Generally you should use the unload event in the body (in jQuery for instance, just add
jQuery(window).unload(function(evt){
if(!confirm('Do you really want to leave')){
evt.preventDefault();
}});
Prototype have something similar, and for pure Javascript, I guess that it still depends on the browser you're using, but window.unload = function(evt){return false;} might work.
Don't remember the correct syntax for it though.
but I do not know if you can limit that for only the back or if it will trigger for all the unloads (like clicking on a link, closing the browser etc.)
If you want to stop them because they might have unsaved data in a form, then that is ok. If you want to stop them from going back for another reason than that, I think you should rethink why.
Generally if using the back button can cause issues you already have bigger problems.
What you probably want to do is check that you do things like this:
Use POST for all requests that alter data
Use nonce's (unique ID's) to enure forms don't get submitted twice
I use noscript for this very reason. I insist on having control of my browser not the site that I am visiting. I only allow scripts for certain sites. For any site that disables my back button,I don't allow it to run scripts.