How to prevent back event bubbling form inner iframe from another domain - dom

I have a page hosted on, say, www.domainX.com. In my page there is an iframe, src attribute of which is set to www.domainY.com (so it's on another domain). There are some links on the page served from www.domainY.com (so they show up in the iframe). When I click one of these links there happens the navigation inside the iframe. Now, when I move the cursor on iframe, right-click and select 'Back' on the appearing menu, it makes a back in the inner iframe. If I do the same thing again, it does a back on the main window, as if I pressed the back button of the browser (or I right-clicked out of the iframe and selected 'Back').
My problem is: I am OK with back navigations in the iframe, but I do not want them to bubble up to the main window. I can alter the source code of the page on www.domainX.com, but I don't have access to the source code of the page on www.domainY.com . I tried attaching an 'onback' handler on the iframe element, which stops the event propagation; but it did not work. Any pointers will be appreciated.
Thanks

Related

The route.first page (MyHomePage) is updating even without a callback, function or notification listener

I can't really share code for this as it's for my entire ~large~ application, but is it normal for a flutter application's lower navigation stack to be updated when the current page is?
For example, in this page I have a standard form with a few TextFormFields:
Whenever I click on one to start typing the page sets state as expected, but by adding print("Update"); inside the build function of the bottom page of the navigation stack, I can see that page is being updated too. It happens on all pages I put on top of the first route page. I've also been experiencing that the home page gets slower as the app has been open for longer, could this be a cause for that problem too?

Browser Back Button Cause Dynamic Content to Load

I am using Wordpress, with a plugin called "Visual Portfolio" It has a feature that allows some of the content to load, then when you scroll down, it loads more portfolio thumbnail content, like an infinite scroll feature for pagination.
The problem is, this makes it so if content is loaded dynamically, when they go to a portfolio item, then press back, the content is not loaded in the same way, and they can't easily go to another portfolio item, without scrolling down again.
Is there any way to solve this, so when they press back, it loads the page the way it was when they were their before?
Thank you for your attention on this

How did Facebook implement the chat sidebar?

I'm trying to understand how Facebook implements the chat sidebar. It seems to stay there even as I change pages. For example, if I select some text inside the sidebar, then click to go to another Facebook page, the text remains selected. It's as if it was a separate frame, but when I look at the code, it's not.
All requests are made trough AJAX calls. Only "content" container is replaced when needed.
You don't actually "go" to another page. Just the "content" div gets updated.
There is a container DOM element called "fb_content", its content is replaced through straight-forward AJAX or more technically XMLHttpRequest. (Although when for example you enter an app, the entire page is refreshed.) To update the address bar they use the JavaScript History API.
In addition to what Zeno and lericson said (fb_content gets updated via ajax), the address bar also gets updated while maintaining the history (if you press back/forward).

GWT activity mayStop and Hyperlink issue

I have an activity with a mayStop() method. I am having two issues with it that pertain to a hyperlink on the page.
The first issue is that if I hit refresh or the window's X I get a dialog box that wraps my mayStop() text with "Are you sure you want to navigate away from this page?" and "Press OK to continue, or Cancel to stay on the current page." That is fine.
When I hit the hyperlink, I only see my mayStop() text without the wrapping text. Why is that?
The second issue is that if I hit Cancel in response to the hyperlink click, hitting the link again results in not getting the mayStop() challenge at all. It is as if I am not hitting the hyperlink.
Has anyone run into these issues?
Any thoughts?
Thanks,
Doug
The difference in "behavior" is that the first dialog box is the one from the browser when you try to prevent the user from navigating away, while the other is PlaceController calling Window.confirm(). Each browser uses a different dialog box for the first case, so there's no way to mimic it for everyone, and it's probably not a good thing either (navigating away from the app vs. navigating within the app).
As for your second issue, the events are generated by the browser "history" changing; if you prevent navigating away (from the Place), the URL stays the same (there's noway to know what to do to "rollback" the change: History.back(), History.next(), History.newItem() but then you destroy the existing "next" history ?), so when you click again on the link, you don't make the URL change, and no event is fired.
It's expected that you use PlaceController.goTo to navigate when you use places, not Hyperlink or History.

How are the facebook chat windows implemented?

On Facebook you can browse the site without affecting the floating chat windows. Seems like if the main page was inside an iFrame and the footer and chat windows where floating outside.
(source: k-director.com)
Is the main content inside an iframe or are the footer and chat windows the ones inside an iframe?
The later doesn't seem possible because int this case when you click in a link in the main page everything would have to reload, including the footer iframe.
If you refresh the page the chat windows are reloaded, but if you browse the site by clicking links they are not.
Thank you.
If you install FireBug and enable the net monitor for Facebook, you'll see that when you click most links inside the application, you're not doing a full page refresh, but rather an AJAX call which updates the page with the new content.
It looks like a new page, but in reality you're on the same page with just about everything but the chat-bar replaced.
Probobly just an absolutely positioned div, containing a scrolling div for the content. Ajax would provide the content.
The chat windows do indeed refresh when you load a new page, they maintain their viewstate however (open/close/chat history).
It's an absolutely positioned div, positioned at the bottom of your browser window. It's not hard, I cloned the Facebook chat for ClockingIT from scratch in a weekend.