The add-on will only work with the new Twitter design, as per July 2019. You may find a handful of options (including but not limited to the customisable conditions for the auto-refreshing procedure) through the Mozilla Firefox add-on's page ( about:addons). The primary goal of this add-on is to allow you to continiously read Twitter whilst doing other things on the side (e.g. Takes up the challenge of fixing the bug.A Mozilla Firefox add-on that automatically reveals unread tweets every set seconds on Twitter feeds, so long as the customisable conditions are met. Is an open source application, there is no single corporation or company we canĬontact regarding their bug." So it doesn't sound like this is going to beįixed any time soon, unless someone who's familiar with Mozilla's internals Said "Because this bug exists in Mozilla, DCLK cannot fix it. Nobody at Mozilla seems to be interested in fixing this. Slot, the Digg button shows up in an ad's slot, etc. Have noticed 3rd-party ads showing up in the wrong slots or nothing at all in a Get its content loaded into another IFRAME on the page. It turns out this is a Mozilla bug, NOT a Facebook bug.įirefox has a problem where sometimes when a page is refreshed, any IFRAME may Other browsers don't do that.įacebook and Google blames Mozilla for this bug as stated at
#Mozilla firefox refresh page manual#
Manual refresh heals it sometimes, but sometimes not. When FF "Back" and "Forward" buttons are pressed several times, they starts to display itself in each other iframes. This bug is very noticeable with Facebook "Like" button and Google AdSense ads (both use iframes). We could also try for some heuristics with vs, but that starts getting. Yet another way to "fix" this would be to stop restoring subframes from history altogether, but that degrades the user experience enough that I'm not sure it's worth it to do that. That could lead to some odd behavior where what you see on reload depends on whether your cache entry for the toplevel page got evicted or not. The problem in this bug is that the dynamic addition is happening on the _server_, effectively, so is opaque to us.Īnother possible way to solve this would be to not restore subframes from history if the page being reloaded was a cache miss. Note that we fixed the somewhat similar situation of a document.write that writes out a different URI by treating those frames as dynamically added. So we can't just have a bugzilla attachment that shows the problem. To reproduce this bug as filed you have to have a page that when reloaded hits the server, and you have to have the server return an with a different src than the page had for that iframe when it was loaded the first time. > Would be great to have a testcase attached to this bug. I didn't I code-inspected the JSP in comment 0.
Still not convinced? Try this in Opera, Konqueror, Internet Explorer or Safari. Try hitting F5 in quick succession if you find difficulty in recreating the problem. Note: this may have something to do with the DOM not fully loading. If the site you see in the iframe is not the same as the site stated, then just check the source of the page to see where the iframe points to. Keep hitting F5 and check to see if the page you see matches the page stated above the iframe.
This page randomly chooses between showing, and in the iframe shown below. to demonstrate this behaviour.*/įont-family: Verdana, tahoma, sans-serif *Here is an actual JSP that you can use within Tomcat or Resin etc. The contents of the iframe to be the same as the src value of the iframe element. The contents of the iframe are different to the src value of the iframe element. Each time the page is accessed/refreshed, the source element of the iframe will be one of either site mentioned.Ģ.Access the page and keep refreshing and checking the source value of the iframe element and look at the contents displayed in the iframe.ģ.After a short number of refreshes using ctrl-r or f5, you'll find that the physical content of the iframe is different to the source value of the iframe element. When viewing the page via the DOM Inspector extension, we see that the src element of the iframe points to one location (URL), while the contents of the iframe are from a previous page reload.ġ.Create a JSP page that has an iframe that points to either or. The user refreshes the same page X number of times (usually 2+) which hits a different third party advert each time via a change of the src attribute of the iframe.ģ. A user opens a page with an iframe that contains a Flash advert from a third party.Ģ.
I have noticed that iframes do not always show the correct contents when refreshing a page.ġ.
0 kommentar(er)
