I am looking to use the DTM tool to load a synchronous third party javascript before DOM ready and not on page load. Is this possible?
Adobe DTM has four main Load Order Types for controlling when a page rule is evaluated, two of which occur before DOM ready: "Top of Page" and "Bottom of Page".
Within the rule, for 3rd party script tags, you can choose various options for loading the tag sequentially (synchronously): "Sequential HTML", "Sequential Javascript Local", and "Sequential Javascript Global".
Note: DTM makes use document.write to accomplish this functionality, which may be blocked by users who use Chrome on slow internet connections.
Related
This is a scenario for which i need to check the feasibility.
Suppose I have 2 different analytics tools. Let say Adobe Sitecatalyst and Mixpanel. To work with DTM these tools need to be integrated with DTM.
After integration, specific rules will be created. Question is -
Can we create 1 rule, and use it to send data to different tools simultaneously or we need to create different rules.
Answer is yes. You can create a single rule and customize the Adobe Analytics section to send whatever you need (using eVars, props, events, etc.). You can also create a third-party JavaScript tag (as part of the same rule) and customize the pixel for Mixpanel.
DTM is really one big JavaScript editor. If you can create JS tag, DTM can execute it.
Hope this helps.
Mark
Based on the jQuery Mobile docs, the <script> tags to load jQuery and jQuery mobile should go inside the <head> element.
I've always been told to load <script> tags at the bottom of the page for better performance. For example: http://developer.yahoo.com/blogs/ydn/posts/2007/07/high_performanc_5/
Is there a reason to prefer one location over the other for jQuery Mobile scripts?
Putting the <script> at the bottom is to facilitate faster loading of external elements before code executes, but in jQM nothing will really show until the pageinit/pageshow events fire, which is basically jQM's version of document.ready (everything is loaded and the DOM is there etc)
I can imagine in larger sites where you want content to be displayed ASAP this would come in handy, kind of like attaching passive on listeners even before the document.ready is another trick people use.
But all these speed optimizations don't mean much when you're waiting for a document.ready to display anything.
I'm trying to write a Firefox extension that speeds up browsing page sequences by preloading sequence items, preprocessing them, and showing on request.
Is there any way to load and process DOM of arbitrary web page (on the same site as currently opened) in background from privileged extension code?
Ideally, the document's javascript should work as it would in a normal browser window. I suspect a hidden window would be required for this. The context on that javascript should not be privileged then.
Loading should allow user to continue normal browsing in all visible browser windows.
I don't like the idea of injecting iframes to currently opened document and making them optionally visible (the principle used by Webcomic reader userscript)
From the add-on SDK, the page-worker module might be close to what you need:
The page-worker module provides a way to create a permanent, invisible
page and access its DOM.
That said, I have no idea whether it's possible to load that invisible page into a (current or new) tab / window. You might be able to replace a current tab's document.body by the page-worker's one. Possibly. If it's legal.
You could use a lightweight browser extension to collect all links on a page onload and use link tags to prefetch the content for each, the browser will load those pages in the background: https://developer.mozilla.org/en/Link_prefetching_FAQ
OR
If you need to preload a page and have access to its DOM from extension land, you could use the Page Worker API from the Add-on SDK: https://addons.mozilla.org/en-US/developers/docs/sdk/1.0/packages/addon-kit/docs/page-worker.html
I believe so. assuming your javascript is already running
var doc = gBrowser.selectedBrowser.contentDocument;
will get your the document of the loaded tab, you can then process it and do with it what you want. Doing it in the background and keeping the app responsive is a different story :)
I've not written an iOS app and want to know if what I want to do is reasonably easy before I invest all my time in it. The idea is simply to leverage the built-in webkit methods to write my own browser. I've seen tutorials where this is done fairly easily. However, the twist is I want to apply some rewrite/regex rules prior to the page rendering. ie, you load http://example.com which is a page containing the word 'foo'. Prior to displaying the page, the app rewrites 'foo' to 'bar' and renders.
Is this possibly to do easily without actually writing a ground-up browser?
Thanks!
It's doable (assuming you're using the standard UIWebView component to render the page), and there are a few ways you could go about it. Among them:
You could download the HTML and parse it via Objective-C string handlers before loading it into the UIWebView
You coud use load the HTML as-is and use the UIWebview's stringByEvaluatingJavaScriptFromString: message to "inject" javascript onto the page, manipulating the DOM itself
You could go the Opera route, and pre-render the page via a server-side proxy before downloading it to the client.
How far down the rabbit hole you want to go would be up to you, of course. Easy is in the eye of the beholder.
I'm trying to get my Chrome extension working with the Google Calendar API. However, the way Google has set up the extension sandbox makes anything almost impossible.
I can't add the Calendar API using JavaScript because I've tried 200 different ways to include the http://www.google.com/jsapi library. Therefore, I want to try interact with the Calendar API with PHP. Is it even possible to do a POST from a Chrome extension in order to run my PHP file? If not, it's pretty much impossible to interact with any external API that doesn't have a downloadable library, isn't it? If that's the case, I don't see how you can make anything useful with Chrome extensions.
I think you are still having difficulties because you don't completely understand the difference between content scripts and background pages.
Content scripts have certain limits. They can't:
Use chrome.* APIs (except for parts of chrome.extension)
Use variables or functions defined by their extension's pages
Use variables or functions defined by web pages or by other content scripts
Make cross-site XMLHttpRequests
Basically all they can is access DOM of a page where they were injected and communicate with background page (by sending requests).
Background page thankfully doesn't have any of those limits, only it can't access pages user is viewing. Good news is that background page can communicate with content scripts (again through requests).
As you can see background page and content scripts supplement each other. If you use both at the same time you have almost no limitations. All you need is correctly split your logic between those two.
As to your initial question - content scripts can't make cross domain requests, but background pages can. You can read more here.