I've got a communication between client and server. The process is simple:
I'm making an AJAX POST request to a controller which generates a pdf in the file system
On success of the above request a form GET request is made to get the pdf back and the standard browser "save or open" dialog box opens up
The reason I'm having a two step process is because I need to have a progress bar while the pdf is being generated.
The reason of the second request being a form submit rather than part of the AJAX request is because I can't get the standard browser "save or open" dialog box.
The problem with this approach is that IE7 & IE8 pop up a their annoying notification bar notifying the user that the it is dangerous to download the content and I don't want that.
So:
I need the progress bar.
If I go for an AJAX request only I need a way to pop up the "save or open" dialog box.
If I go for the a form GET submit I need a way of knowing when the file has been generated in order to stop the progress bar, something like a shared flag between server and client.
Any help appreciated.
One possible (a little of an anti pattern) workaround is this, but it's not a great design probably
However I've seen this (and admit I did this) before, and except some guilt, it did the trick
user clicks a link that goes to the servlet that generates the PDF and will just wait (timeout settings should be applied) until it's ready... (Content-Disposition header etc...) just like a regular download
The servlet will report progress on a shared session variable while generating the PDF
an AJAX call to the server will read from the session variable the progress and show to the user
when the PDF is done, the browser will just download it (request timeout risk perhaps)
The main issue here is using the request thread as a worker thread and blocking it, which may give this answer a couple of downvotes...
I'm not that familiar with Message Driven Beans but this is another, probably better solution.
Related
The question is probably easily misunderstood, so I'll go into more detail:
I am trying to automate a task in a certain (very outdated) browser-based idle game that is written in PHP in order to polish my portfolio with a little more variated projects.
I used DevTools to reverse most of the requests and wrote a small C# Request wrapper to test them. I can get most of the actions I want to work, using the respective ajax get requests and the correct cookies/headers - not really part of the problem.
Example:
Attacking an enemy:
https://somebrowsergame.com/game/ajax.php?mod=location&submod=attack&location=3&stage=2&premium=0&sh=****mysessionhash****
Making a GET request to this URI with the correct headers and cookies, I can perform the in-game action programmatically and successfully from my C# console application and see that the fight has taken place when visiting the site in the browser.
The problem:
When monitoring all requests after clicking the "attack" button, via DevTools, even with preserve logs enabled, I don't see any redirects or way of determining how my browser gets told where to navigate to.
Findings
I found out that the button calls a javascript function attack() in its onClick event and tried debugging the javascript in DevTools in order to find out where somethign happens (such as setting document.href or smth), but when Debugging I ran into a seemingly infinite loop of setInterval handler and setTimeout handler in the call stack.
I also cleared the Network tab after the onClick event (and after the ajax request which I could find during Debugging) but the only request/response I got was the document GET request for the final page, no request telling my browser which site to navigate to.
Monitoring requests
The request made to initiate the action (via button click on website or ajax GET request as outlined above)
The document response / site navigated to
What I want to know is how my browser got told which site to navigate too, as the request URI for the document request (getting the html of the target page) has a parameter generated on the server side (logId)
I have also used "All" request types in DevTools, as well as negative filters when monitoring requests but never was I able to see how my browser knows which page to navigate to. I tried with source breakpoints at "beforeunload", tried inspecting the javascript source connected to the onclick event of the button (which didnt give me anything, as the js is minified and barely readable - i am not even sure if the navigation is done via window.target.href) and googled this question in all possible wordings which lead me nowhere
I am not too versed in web development, but I am sure my browser has to be told where to navigate to in some fashion after clicking that button?
We have an ember single page application. On a specific page, while clicking on a hyperlink, I want to open a specific route in the new window.
The problem here is, it starts downloading all the js files (main.js) and authenticating the session and then only it is loading the route. This is taking too much time and giving a poor user experience. Since the hyperlink can be clicked only when the user is already logged in, is there a way to avoid downloading all the js files and authentication in ember? Something like a child window of the current window, so that the route will be loaded immediately.
is there a way to avoid downloading all the js files
They should be cached by the browser unless you have your server set headers to not cache your JS files.
But maybe the files are loaded from cache but the delay you are experiencing is the parsing and execution of your scripts. This cannot be avoided with a SPA.
You could shorten the perceived delay by using server side rendering via FastBoot. This will mean the route is immediately rendered, but the user won't be able to interact with it fully until all of the client-side scripts have been executed.
authentication in ember
I don't think this adds much delay as it should just be checking a cookie or HTTP header as you are already authenticated in another window.
Something like a child window of the current window, so that the route will be loaded immediately.
As you have a SPA, you should try to avoid opening a new window as everything is already loaded in the current one. And the user can easily return to the previous page via the browser back button and this too should be almost instantaneous.
Is there a particular business reason why it has to be in a new window?
I am using the CefSharp .Net wrapper for the Chromium Embedded Framework as a simple wrapper around a web application. In my web application, I make a JSONP AJAX call out to another domain to get some data and display it. The URL to that domain is not using SSL. Because of that, when doing this in the Chrome browser, I get the following message, to which the end user would simply click "Load Anyway", allowing the JSONP request to fire and the data to be retrieved...
The app using CefSharp simply starts up the main URL to my web application when it runs. When I try and make the same call in my this application using CefSharp, however, it doesn't get that same prompt. Instead, the AJAX request just times out (the same behavior that happens when the end user never clicks a button in the yellow bar that appears in Chrome).
Does anyone know if CefSharp has a way for me to catch this security message and either...
Prompt the end user to click "Load anyway", similar to the behavior of the Chrome browser, or
Programmatically bypass the security warning altogether?
If not, does the Chromium Framework itself support dealing with this situation?
After posting to CefSharp and CEF projects, it looks like CEF does not currently support this situation. magreenblatt suggested a couple of approaches to add it to CEF. Now I just need to try and find the time to add support for it. :-)
I am a beginner using ajax and I always thought that it is completely asynchronous. But I discovered that a call can be interrupted by a page reload or a page change (like clicking on a hyperlink). I was under the impression that when an ajax call is started, it is carried out no matter what the browser does afterwards. Is that wrong?
Now to the specific problem I am having: think of an online test where users answer questions (by typing into textboxes). When a textbox loses focus, an ajax call is triggered which persists the value of the textbox to a DB. That works well when changing between textboxes. However, I also have a submit button which triggeres a post action to another page (it is the submit button). When I enter something into a textbox and click on the button afterwards, the call is not carried out. Moreover, when I type into a textbox, click somewhere else (also triggering the call) and swiftly click on the submit button, the call is also not made. Is that expected behaviour?
The reason I am using ajax in the first place is to persist the values so when something unforseeable happens, like a browser crash, the already typed in text is already saved.
Is my way of thinking wrong? How would you go about solving this problem?
Thank you for your time!
AJAX is asynchronous.
When you send an AJAX request the javascript engine sends it off and sets up a handler for the response.
However, if you send an AJAX request to the server and then navigate away from the page before it is received, nothing will happen. Why? Because with each page load the entire Javascript environment is tore down and reinitialized, it has no idea what happened on the last page.
For your problem I would intercept the form submit action and do whatever you need to do with the data, and then submit the form.
Edit: In response to your comment. You are correct. If the ajax request is sent, and you're not depending on it's return value, then it should not matter.
I'd suggest debugging your problem with Firebug to see if the AJAX call is really being sent properly, and to confirm your server is properly processing it.
Unless you do something special with persistent local storage, all javascript and ajax calls are blown away when a new page is loaded over the current page. Also when a submit is done on a form.
To save things intra-page, save the data asap. Eg, perhaps save on key-up, perhaps periodically with a timer, not just on lose-focus.
Re submitting the page: change the on-click behavior to first store, then to go to a new page.
All of the effects that you are seeing are normal.
Also, be sure to test on both slow (ie 6 or 7) and fast browsers (chrome)
I am implementing a web application using ASP .Net and C#. One of the pages has a requirement that it always needs to be fetched from the server, rather than from the local browser cache. I have been able to achieve this.
We have a back button in the application, which simply invokes javascript:history.back() method. The problem is that when the back button is clicked to navigate to the page which is always to be reloaded from the server, the browser displays a "Web page expired message".
The intent here is to force the browser to reload the page rather than display the web page expired message.
Any help would be highly appreciated. Thanks a ton in advance.
You will probably need to change the implementation to make the browser load the URL explicitly:
window.location.href = 'http://....';
instead of invoking the back button, since the intention of the back button is to get the last page from the cache.
(If browsers would not act that way, they would re-send your form data multiple times when using the back button during a registration process or similar.)
You mean you want to control browser behaviour, which is not possible. I doubt you can solve it that way. You could set the expiration time to a small value (1 minute perhaps?) so that the page is still valid if one navigates back quickly.