I am trying to block URLs with a certain keyword in a JavaFX webview. So far, I have tried using webEngine.locationProperty().addListener() to listen for a change in state. While this is successful in blocking the URL, it unfortunately leaves the locationProperty set to the value that I am trying to block. This causes problems for links that use references on the page.
Two solutions I have tried for setting locationProperty back to its correct value:
Calling webEngine.load(). This causes the page to refresh and the user loses work.
Calling webEngine.getHistory().go(0). As it says in the documentation, this does nothing.
I can think of two general ways to solve this problem:
Find a place earlier in the chain of properties than locationProperty that gets changed to listen.
Figure out a way to change locationProperty back to its correct value without reloading the page. (I think this might be possible through reflection which I've been trying to avoid up to this point.)
Do either of these solutions sound reasonable and if so what is the best way to implement them?
Related
I'm using the fetch API to display a webpage inside of a floating widget. The page has a form on it that uses viewstate. It works fine if the widget is on the same domain as the page I'm fetching, but if I put the widget on a different domain, then I get an invalid viewstate error. I have tried several things to resolve the issue, but none work. Does anyone know if it's possible to get this working?
No. If by your definition of widget you mean something like an iframe then this would cause issues regarding XSS if you are trying to manipulate data between the parent frame and iframe, it wouldn't if the domain was the same though due to the same-origin policy.
I have a custom multi-step form that I add to certain node type content via hook_nodeapi. It is working great, with one exception.
During testing, I've found that when I am in mid-form (say, step 2 of 6) and update the node in another browser tab, my form reverts to step 1 when I try to proceed to the next step. Similarly, when an AHAH event occurs, I get an error and the form disappears altogether. The error suggests there is a problem with retrieving the form from cache after a node update, as it's not able to retrieve the form parameters.
Have you encountered this behaviour before, and/or do you have any suggestions on how I might go about fixing it? It isn't a huge problem as these nodes likely won't be updated too often on the production side, but it would still be a significant nuisance to those it does affect.
Edit: Thanks for your response. Unfortunately I can't contain this form within a block. It must be within the node content itself. Upon further testing I noted that other users thankfully aren't affected. It is only the user that updates the node while in mid-form that is affected. As this is extremely unlikely to happen on the production site, the impact of such an occurrence would be minor, and I have no time at the moment to explore this further, I'm going to move on with this behaviour unexplained for now. But if anyone can point out why this is occurring, I'd appreciate it.
Well, have just tried your situation based on multistep form described here - http://zgadzaj.com/basic-drupal-multipart-form-example-with-previous-and-next-buttons - but put in the block and displayed on node page, and even if I edit this node in a different tab, I still can navigate between all form steps on the original tab, keeping all already submitted values. So I'd say it all probably depends how your form is being built...
My web-app records users via webcam and microphone. I want to use HTML/JS for the controls and content, so I created two separate Flex modules:
* A "Webcam Setup" module that lets you choose your camera and mic input devices
* A "record" module that lets the user record and submit the recording
When I embed either of these on the page, since they access the user's Camera/Mic object, Flash shows the Privacy dialog that says "[mysite] is requesting access to your camera and microphone. If you click Allow, you may be recorded."
The problem is, if I answer Yes in the Setup module, and later add the Record module to the page using Javascript, it again shows the Privacy dialog.
Is there a way to avoid the second privacy popup?
I would think that saying "Yes" for [mysite] would store that permission for at least that session, but apparently not.
What I've tried
I tried combining them into one SWF, adding it to the page once and moving the DOM element with jQuery's append() function when needed. When I move it, however, it reloads and asks me again.
Imagine if [mysite] was, say, blogger.com or livejournal.com (or, if it were still around, geocities.com). Would you want a "yes" response on that site to be good for every page under that domain?
Rememeber, just because you promise (cross your heart & hope to die) not to abuse the security hole you request, doesn't mean they can allow you to have that security hole.
Eventually, I found a usable workaround, similar to what I originally tried (above).
I combined the setup and record modules into one SWF. I first show the setup screen. When the user hits the Continue button on my page, Javascript calls a function in the SWF to swap to the Record screen.
I then move the <div> containing the Flash object to another location on page using absolute positioning, and resize the object.
Previously, I was trying to use jQuery's append() function to move the div within the DOM, and that was causing the SWF to reload. Just changing position and size does actually work.
You could build the "record" component to simply send and receive signals using an API you've created for your "setup" component (which has already been authorized, meaning one auth & two swfs) by using the LocalConnection class:
http://livedocs.adobe.com/flex/3/langref/flash/net/LocalConnection.html
This seems far closer to best practice than the other implementations mentioned, which smell a bit hacky and would probably confuse anyone who may inherit the codebase in the future.
we deliver micro-site content for our client. Our content is injected into a wrapper that is supplied by another developer.
To deliver our content we host the wrapper as well as the content. The user can access this at
http://fundcentre.[redacted].ie/ (try a search for '[redacted]')
For the other content that is not ours, the other developer hosts a similar (though slightly different) wrapper and delivers the content. the user accesses this here:
http://www.[redacted].ie/ (try a search for '[redacted]')
The wrapper contains a search box, which does not work for us but it works for the other developer. I took a look at the network traffic with FireBug but it appears that when I do the search from the wrapper that we're hosting, I'm getting a "407 Proxy Access Denied" error. My guess is their proxy has a problem with the fact that the search is being conducted from a page hosted outside the scope of their proxy.
It was also suggested that there were javascript errors on the page that were preventing the search from executing but I can't see any. Also, I don't think I'd get as far as the proxy error if that was the case.
I don't really understand this stuff too well though, so could somebody with a bit more experience please take a look and maybe shed some light on this for me? Thanks.
The problem appears to be that the search box and the button next to it (the magnifying glass) are both causing the whole page form to submit after they try to set the page URL to the search URL. When you type into the search field and hit "Enter", the outer form that's wrapped around the entire page is submitted. When the magnifying glass is clicked, it tries to load the search results but because it's an image button the click also causes the outer form to be submitted.
I'm not exactly sure how best to fix it, partly because I think the entire page design should be thrown out. But if you're stuck with it, it might be possible to get it working by ditching that in-line Javascript on the button (since it's not working anyway) and then wrapping the search stuff with its own <form> directed to the search page. Having a <form> within a <form> is bad mojo but that's hard to avoid in a design that puts the whole page in a <form> to start with.
Alternatively, you could try handling keypress events on the search input to detect "Enter", and have that handler and the code on the button both return "false" to stop the outer form submission.
edit — as to why that works on the other site, well it appears to me that there the outer form really is the "search" functionality somehow, as they don't have the click handler on the search button at all, so all it'll do is submit the outer form anyway.
edit again — also, I never see that "proxy" issue. The search from your page works fine for me if I first fix the inline Javascript on the button so that it ends with ; return false. That actually may be all you need to do.
It could be a problem that your tags' action are pointing to different scripts. One is pointing to "Home.aspx" and the other to "/Default.aspx".
The two links are in different subdomains, so maybe you would like to change the action of the subdomain so it contains the full location of the action (ex. "http://www.newireland.ie/Default.aspx")
On stackoverflow, and other websites, if you start making a change to form elements and then you try to navigate away from the page, you will get a confirmation message asking if you are sure you want to discard your changes.
This seems relatively easy to do by hand, but impractical to apply across an entire site. Is there any generic solution that can be plopped onto a page as a control (or even jQuery plugin) which will track IsDirty for all fields (without having to specify each field by hand)?
You can use the window.onbeforeunload event.
See also How can I override the OnBeforeUnload dialog and replace it with my own?
A possiblity would be to clone a selection of all your inputs when the page is loaded (and data into it as well).
You could then do a compare as desribed here:
http://chris-barr.com/entry/comparing_jquery_objects/
Word of warning though, this may be costly, performance wise.