User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020904 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020904 if I open a new navigator window and click the "Impressum" link on the url above (in the left frame), the back button still appears greyed out and can't be clicked. Reproducible: Always Steps to Reproduce: 1.open a new window 2.load the url from above 3.look at back button Actual Results: button is unclickable Expected Results: back should be clickable

(why was this filed as unconfirmed? ah the joys of bugzilla helper... I'll take the freedom to confirm it, as I intented to file this as NEW anyway) deleting compreg.dat did not fix this issue.

*** Bug 166805 has been marked as a duplicate of this bug. ***

*** Bug 166806 has been marked as a duplicate of this bug. ***

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/2002090311 Back button from Impressum page takes me back to page *before* startpage of http://blitztarif.de/. Clearly, this is also wrong, just in a different way. pi

pi, I guess that that is the same basic problem. did bugzilla/mozilla really submit this three times? arg.

That site uses some javascript (/frames.js) which may mess things up. My JS knowledge is too rusty to offer any more help than that at this point.

related to bug 162567?

Another sites which shows this problem: http://derstandard.at/ This is one of the most important sites for Austria. Der Standard is one of the important newspapers in the German speaking countries. Is this top100 then? pi

djk, if you switch of JS it still happens. So this is not a factor. pi

This bug was in mozilla < 1.0 as is here again in 1.1 as I saw when I installed it.

also see this using trunk build 2002091908 on win-xp pro. +Starting from mozilla.org +going to http://www.derstandard.at +clicking on a story +clicking on the back button --> I'm back to mozilla.org

I wonder if this has something to do with redirections as I can reproduce this bug by doing the following: Go to <URL:http://www.verkkokauppa.com/> (a quite popular Finnish computer store), click their logo with middle button to get the site on a new window. The location bar shows first http://www.verkkokauppa.com/main.php, which then quickly changes into http://www.verkkokauppa.com/ and now the back button (and the corresponding menu entries) don't work normally anymore.

Navigation in framesets is one of Mozilla&#180;s biggest problems. I outlined a solution at http://grassomusic.de/english/grassonaut.htm#navigation can inspire you. A http://server.com/frameset.htm?framexxx=this.htm&frameyyy=that.htm -like representation of frameset states would A) eradicate the worst bugs about frameset navigation, history and bookmarking and B) be usable for adress field urls, see my proposals on the linked page! Of course it would not solve all frameset-related problems, there still exists DOM/Javascript and variables as for example scroll position, frame focus and form entries.

In today's trunk build, I can not reproduce the problems described at http://blitztarif.de/ http://derstandard.at/ and http://www.verkkokauppa.com. Shall hold on to this bug for a while for observation.

I am also experiencing this bug when using the Zope Management Interface (Moz 1.1). It's inconsistent, though, and I haven't been able to reproduce it.

persists with 1.2.1 on derstandard.at

This bug really annoying bug has been in there now for quite some time now - any workaround/fix highly appreciated. Makes for example surfing Austria's top platform [derstandard.at] a pain to use with Mozilla.

I think this is the same bug as 171165.

Can someone check this again, it seems to work OK in recent nightlies.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030117 Still fails for http://derstandard.at/. http://blitztarif.de/ WFM. pi

The simple issue of frame navigation as shown in bug 171165 and at http://blitztarif.de/ seems to be fixed in the latest nightlies. http://derstandard.at/ does something altogether more complicated. Each page that is loaded contains a series of javascript checks and reloads to ensure that the whole page is loaded in context even if you deep-link to a single frame. This javascript page reloading seems to totally fox the history-tracking code. Just for jollies, I looked in IE6 and back/forward navigation at http://derstandard.at/ works OK This may be related to bug 188488, where a much simpler case shows similar symptoms.

Since Blitztarif is WFM. Also, I'm about to send a dupe.

*** Bug 183744 has been marked as a duplicate of this bug. ***

It appears that http://www.derstandard.at uses iframes only (atleast the frames in which content is loaded) and it also uses JS location.replace for most of the subframe loads. Content loaded in iframes will not be recorded in session history. Other links mentioned here http://blitztarif.de/ and http://www.verkkokauppa.com/ sems to work fine.

That sucks. I had a closer look at the Standard's web page. It is completely built in JavaScript. The main page is built with http://derstandard.at/js/site/FrameSet_v3.6.js. I understand that the second part is used and hence iframes. Is there any way to see the actual HTML (after it is written by JS) used to display the page? Anyhow: Evangelism anybody? pi

DOM Inspector may be able to help and the mozilla evangelism sidebar (http://mozilla-evangelism.bclary.com/sidebars/) has a source generator which will reformat the DOM as an indented pseudo-source view. Feel free to contact them directly if you wish.

hi, need some help? i can explain you, how we build the site....

Well, I found it pretty hard to figure out what's actually going on. If I understand http://derstandard.at/js/site/FrameSet_v3.6.js correctly, you use iframes only for Mozilla. It would be easier to drop that and always deliver frames. That would also make this script superfluous. pi

we thougth much about it, but with iframes it is much esier to make flawable content, that is fixed in the window. and also cross-frame content. we only need a new div, that is placed over the iframes in the top window. the iframes are on all browsers exept navigator and opera. so also konqueror can handle iframes (we also in contact with the KHTML developers becouse of their problem with our site)

*** Bug 201744 has been marked as a duplicate of this bug. ***

Why is this bug WONTFIX? This afffects a major news paper and the webmaster seems willing to work on this. Reopening and moving to Tech Evang.

.

We think, that the Iframes could be the reason on this bug. if the site has none of them, it works very well. also @Mozilla 1.4a the bug is on every site. that didnt happened at older versions. an them, the bug only appears to be sometimes.

move...

this bug is also present in Mozilla 1.5b (2003082704) and why is this bug assigned to german?

It is German because the components have been reorganized by language.

The discussion in bug 148794 gives reasons for the current behavior.

Is there any progress in changing the web site of Der Standard? After all browser specific versions are created anyhow. pi

its complicated to change a website, that a website doesnt use a Back button.... i would really help the mozilla to resolve the bug. just tell me how. but on this bug, we cannot change the site in next time.

AFAICS in http://derstandard.at/js/site/FrameSet_v3.7.js there are mainly two way how the main page is created, one using frames and the other one iframes. I'd guess that it would be enough for this bug here to let Mozilla (and his familiy members;-) have the frame version. pi

but the frame version is only a smaler one.... and changing the website is not a solution for this bug in mozilla or? and i see much more sites, where it also doesnt work... but i will díscuss this with the others.# thanks for the input

I think there is some confusion here. Some claim, it is not a bug, but a feature. I don't really understand the reasoning. I think, that every click I make forward should be undone with the back button. There is mentioning of bug 148794 which has to do with iframes and history. Maybe someone can try to explain in easy words why this should not be a bug in Mozilla. pi

I don't feel that evangelism should try to get sites to change their content due to bugs in Mozilla but instead should help educate sites on how to support Mozilla using Standards *and* to help identify product bugs in Mozilla that affect sites and that should be fixed. It is not entirely clear that this bug is a dupe. The owner of bug 148794 is on family leave, is a netscape employee and can't be counted on to fix this. Who can take the lead in finding a developer who can find out a) what the real cause of this problem is and b) assign it to someone who can and will fix it?

Just for information: In the current version (nightly build) the problem with the BACK-button reduces to the issue, that you can not go back before the standard.at history. Within it, the back/forward buttons are accessible.

I still see the problem, that I go too far back. This is annoying. It would be easy if there were just frames (since browser detection is used anyway, that would be easy). pi

*** Bug 227727 has been marked as a duplicate of this bug. ***

DerStandard.at did a relaunch yesterday. After a few hours, where Mozilla was totally blocked (including the contact page!), it now works again with no change to the problem in question. pi

Still no progress. It is really annoying. pi

@pi: thats true. as workaround you can use the navigation controls of the web page. they work very well at derstandard.at because of the great site structure.

setting blocking1.8a2 ? this is really the last bug thats preventing me from deploying a Mozilla Browser. DerStandard.at is a really important page for us here and i simply cant deploy a browser that doesnt work on this page. btw: dont you think that this bug causes a potential dataloss? since i'm no longer able to go back a page where i may have written something in a form

Mathias, this is an evangelism bug and as such the blocking of a milestone has no real effect since evangelism bugs are about convincing a web site to change their content. I looked over this bug and several that were suggested as the root cause but the main thing that stands out is Radha's comment "Content loaded in iframes will not be recorded in session history." in comment 24. Perhaps jst can provide the necessary illumination.

it may be an evang. bug, but it still need to be fixed. clicking on a link should cause an entry in the browser history. IMO it shouldnt matter if its an obscure javascript/iframe that does the work or just a plain a href. so IMHO it would be a browser bug and should be fixed by mozilla. Waiting for others to change their website is just as hopeless as dropping the quirks mode becuase everyone should just use Standard (X)HTML

Mathias, my point is that *this bug report is an evangelism bug report and will not result in any changes to the browser*. If there is a real product bug here, then it needs to be filed as such so an engineer will be aware of it and fix it. Hence, my asking jst for his opinion.

sorry, i still havent figured out all those bugzilla details, but this was the only bug i've found (all other bugs related to derstandard.at are dupes of this one so i thought it'd be a good idea if i post it here) Removing the blocking1.8a2 ? again (and sorry for spaming)

*** Bug 252181 has been marked as a duplicate of this bug. ***

[bug248549notfixed]

so why does it work fine sometimes? if this would be an evangelism bug it should permanently reoccur. but if you're surfing on this site for a while the browser history is completely accessible via back/forward. just not at the beginning.

ok, since i think this is an actual Mozilla Bug and not an Evang. stuff, i've filed a new tech. Bug 257498 and i hope someone can fix this

just FYI derstandard.at added some Javascript code to work around this bug see http://derstandard.at/?url=/?id=1941442 (german only)

recently derstandard.at stopped using frames, so the evangelism issue should be done.

OK