Closed Bug 166807 Opened 22 years ago Closed 15 years ago

derstandard.at - back button does not work on a frameset

Categories

(Tech Evangelism Graveyard :: German, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Biesinger, Unassigned)

References

()

Details

(Whiteboard: [bug248549notfixed])

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** 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
Blocks: 59387
OS: Windows 98 → All
Hardware: PC → All
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


Whiteboard: DUPE
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.
Severity: normal → major
I think this is the same bug as 171165.
Target Milestone: --- → mozilla1.4beta
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
Whiteboard: DUPE
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.
Summary: back button does not work on a frameset → derstandard.at - back button does not work on a frameset
*** 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. 
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → REOPENED
Component: History: Session → Europe: West
Product: Browser → Tech Evangelism
Resolution: WONTFIX → ---
Target Milestone: mozilla1.4beta → ---
Version: Trunk → unspecified
.
Assignee: radha → nitot
Status: REOPENED → NEW
QA Contact: claudius → brantgurganus2001
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...
Assignee: nitot → german
Component: Europe: West → German
QA Contact: brantgurganus2001 → german
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.
No longer depends on: 94468
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
Flags: blocking1.8a2?
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)
Flags: blocking1.8a2?
*** Bug 252181 has been marked as a duplicate of this bug. ***
[bug248549notfixed]
Whiteboard: [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
Depends on: 257498
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
Status: NEW → RESOLVED
Closed: 21 years ago15 years ago
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.