Closed Bug 231244 Opened 21 years ago Closed 16 years ago

A HREF failure when HTML generated on the fly and written to frame of web site

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 132255

People

(Reporter: aqod85, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 The search facility of this web site generates html on the fly to give the search results. The links to the pages do not work in Mozilla but do work in Internet Explorer. The html written to the frame is: <HTML><HEAD><TITLE>Search</TITLE><META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"></HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"><p><form name="searchCriteria"> <input type="button" value= "Search Site" name="searchButton" onClick="parent.searchPage.checkCriteriaAndReport(this.form);"> <input type="text" name="criteria" size=40 value="bespoke"onBlur="parent.searchPage.redisplayTextEntered(this.form);" onFocus="parent.searchPage.redisplayTextEntered(this.form);"> </form></p>Enter search words separated by spaces. Then press Search Site button.<br>To ensure a search word is included put a plus(+) sign immediately before it.<br>To ensure a search word is not included put a minus(-) sign immediately before it.<br>A search word without + or - means it will be included but does not have to be.</p><p><b><a style="color:#FF3333" href="generated_7.html" target="main_page">Bespoke Applications Development</a></b><br><i>This section provides information on having a program written specifically for you to solve a problem within your business. </i></p><p><b><a style="color:#FF3333" href="generated_18.html" target="main_page">Bespoke Style</a></b><br><i>If you cannot find a Template that satisfies your needs then for a fee Essence Computing can generate a Style </i></p><p><b><a style="color:#FF3333" href="generated_34.html" target="main_page">Why Bespoke Software ?</a></b><br><i>Ever needed to: Extract information from a large amount of data ? Interface with an old database ? Enter simple </i></p></BODY></HTML> The html is written to the frame using javascript: setTimeout("parent.main_page.location = 'javascript: parent.searchPage.searchStr';", 100); The html constructed is in searchStr. There also seems to be a problem with showing images that are referenced in html that is generated on the fly. Reproducible: Always Steps to Reproduce: 1. Go to www.essence-computing.co.uk 2. Click on the search and search for the word test 3. Notice that the links do not work 4. Open up Internet Explorer and perform 1) and 2) 5. Notice that the links do work. Actual Results: Links do not link as they should. Expected Results: Gone to linked page I've even used the Javascript Debugger and cannot find anything wrong with the <a href's in the generated HTML
confirming using Firebird 20040115 on Win2k, however I had to search "web" to get results, "test" didn't return anything. Can't view source but when right-clicking on a link (the red text), you can "copy link" and "bookmark link". So it seems like Mozilla recognizes the links but don't make them clickable.
How are relative URLs supposed to be resolved when the frame location is "javascript:parent.searchPage.searchStr" ?
Assignee: general → nobody
Severity: major → normal
Component: Browser-General → Layout: HTML Frames
Keywords: qawanted
OS: Windows XP → All
QA Contact: general → core.layout.html-frames
How are relative paths resolved. Good question but IE manages it and so I suppose it just assumes that the path starts from the location of the HTML file (in this case index.html) that the frame part called main_page is declared in.
Presumably the base URI of a wyciwyg: or javascript: URI is the base URI of the page that generated or linked to it, no?
The base URI of a javascript: document is the javascript: URI. The base URI of a wyciwyg: document is the URI that was loaded in that window before the wyciwyg: URI, it seems. That sounds like a nasty hack to me. There is really no way for the channel to communicate to the new document what the old document was, that I'm aware of. Nor do I think that our behavior for javascript: should be changed.
Are you trying to say you think that the behaviour for javascript is correct in Mozilla. If so I cannot agree. I have a number of javascript books where the examples do what has been done and they expect it to work. And it does in IE and I can see no reason why it shouldn't in Moz. Surely the frame handler can access the base URI of the whole framed document and make the assumption that it is where to start from ? If the behaviour is not changed then the only solution I've found so far is to change the <a href generated so that it references the explicit page on the server. So: <A HREF="generated_1.html" target="main_page">blah</a> becomes <A HREF="http://www.essence-computing.co.uk/generated_1.html" target="main_page">blah</a> I personally don't think that this is a step forward. Nor do I feel the web site creating public will flock to this new standard. You say the base URI of a wyciwyg: document is the URI that was loaded in that window before the wyciwyg: URI and that this is a nasty hack but for me this would work since the last URI loaded is in the same location as the new docs I want to link to.
Mozilla is buggy: base URI computed when resolving a link depends on target, not current, window or frame. The frame named main_page has the right URL on which to base the relative URL computed in the search frame. If general@dom.bugs is wrong, someone please correct the assignee. I didn't want to leave this assigned to nobody. /be
Assignee: nobody → general
Grrr. /be
Status: UNCONFIRMED → NEW
Ever confirmed: true
> base URI computed when resolving a link depends on target, not current, window > or frame. Er... NO. The base URI depends on the current NODE (since you can set base URI per-node in XML). It absolutely does not depend on the target. Setting dep on an old bug that maybe has a behavior change for this, btw.
Depends on: 49312
bz: I'm telling you what a bunch of us implemented back in 1995 or so (Nav 2 and above; 2.0 was when frames and JS debuted). On what authority do you base your "NO"? Is there yet another w3c spec flying in the face of reality? /be
Of course, I'm not remembering how the old codebase managed to resolve a relative URL using the target window's base URL. It wasn't during layout: the old ebina layout engine just made an absolute URL using its current-window&document-based notion of base. Hmm. /be
Brendan, my "NO" is based on what every single browser on the market implements (well, I just tested NS4, Mozilla, Opera, Konqueror; I have no IE here). None of them resolve relative to the target frame. The specs just happen to agree with that. So we should definitely be resolving relative to the frame the anchor is in. The question is what the base URI of that frame is.
bz: right, sorry -- cleary, I was confused. The issue is the base URI, which (now that memory returns) in Nav 3 and 4 for *any* generated document, whether document.written or parsed from the non-void result of a javascript: URL, was a wysiwyg: URL. That kind of URL contains the URL of the generating script's page, such that when a relative URL is resolved against it, you get the absolute URL based on the generator. Mozilla revived wysiwyg: as wyciwyg (what you Cache ...) but only for wholly-generated-by-document.write pages, not for partly generated (by one or more document.write calls from top-level script(s)) documents, or for pages generated by javascript: URLs. Those uncovered cases seem like bugs in their own right: such wycywyg:-less pages can't be refreshed from cache -- their generating script(s) must be rerun on each reload. jst, peterv: isn't there already a bug on file asking for wyciwyg: URLs for partly-doc.write-generated and wholely-javascript:-generated pages? /be
Man, my spelling is atrocious. New baby, not enough sleep. Anyway, apologies again for misremembering what was behind this. It's all in the wysiwyg: magic, whereby http://generator.script.com/something becomes wysiwyg://some-id/http://generator.script.com/something. /be
So in summary, as I said in comment 4, the base URI of a wyciwyg: or javascript: URI should be the base URI of the page that generated or linked to it. :-)
People who actually care should see what the patch in bug 49312 does and whether it can be resurrected.
Hixie: quite right! And what's more, in Nav 3 and 4, a javascript:-generated document had as its base a wysiwyg: URL, so the two cases (all generated document cases) collapse. People who don't care about compatibility can depart this bug and it will never darken their doors again. I think we ought to fix this, so I'm sticking around. I can't help test bug 49312's patch right now, and it looks old and musty. Maybe there's a better way now. jst, peterv: is this a dup of bug 49312? Is there any reason to use wyciwyg: URLs for partly-generated (by scripted document.write calls during load) pages? Is there any reason to use wyciwyg: URLs for javascript:-generated pages, or do we refresh from the content model in all cases? A lot of the motivation for wysiwyg: URLs in the old codebase came from its reload-on-resize layout design. Resizing should not rerun scripts, especially document-generating scripts. What made this worse was the habit of Nav3 and 4 of reloading frame documents on resize, because frames (but not their top frameset) were destroyed and recreated on resize. If spurious resize-reloads are not an issue, then why do we want wyciwyg: at all for the case of a page entirely generated by document.open/write? It seems like sauce for the goose. /be
> If spurious resize-reloads are not an issue, then why do we want wyciwyg: at > all for the case of a page entirely generated by document.open/write? It > seems like sauce for the goose. Because people expect the document.written page to exist in the following places: 1) Session history (go back to it after clicking a link) 2) Cache (reload, view-source, save). And we need to have some way of referring to it in the cache; that's where the wyciwyg url comes in.
We _could_ probably try to hook things up so that a javascript: channel's URI was a wyciwyg URI (and the originalURI was the javascript: URI). That would require moving the wyciwyg stuff somewhere out where JS channels can see it, of course. And frankly, it all needs some de-magification, imo.
bz: yes, the Back button -- exactly. Mozilla currently re-executes the javascript: URL to generate a page on Back, which is wrong. If the generator has side effects or rolls dice for a new fortune cookie, or whatever, the user sees a new page, instead of the cached old one expected for Back. Ok, so which bug should we use to track the work to generalize wyciwyg: properly to cover all generated document cases? I agree the current document.open/write wyciwyg: code is mislocated, and too magic. /be
May as well do it here, since here has the relevant discussion, I guess....
Keywords: qawanted
Anyone planning to take this? If not, I'll do it. /be
I confirmed too with Mozilla 2004011809-trunk/Win-2K. "Search Site" button in HTML generated by "SEARCH" button returned nothing. (Image of "Search Site" button was displayed.) Next message was issued on JavaScript Console ; > Error: uncaught exception: Permission denied to get property HTMLInputElement.value The first error is "Cross Site Scripting". Frame Info of this Frame says ; > URL javascript: parent.searchPage.searchStr Sorry but I could not find other information related to BaseURL or URL etc. of this Frame in DOM Inspector - too many Frames with no ID attribute! I do not know what domain/subdmain is used on permission check nor whether permission check in this case is proper or not. But I think "Cross Site Scripting" in this case can very easily be avoided by simply writing HTML to target frame by document.clear&document.write to target Frame(normal and usual implementation) instead of location change of target Frame to "javascript:xxxx"(very unuasul implementation) when "SEARCH" buttion is clicked at other Frame.
I've reported a bug which shows this problem and it might be a dupe of this one <a href ="https://bugzilla.mozilla.org/show_bug.cgi?id=270414">#270414</a>. I suppose its up to you guys in the know as to whether its a dupe or not. The attached files on that bug show the problem quite nicely and it also shows this bug appears between 1.8a1 and 1.8a2 and also between 1.7.3 and 1.7.5
Fixed by checkin for bug 44504. The test for bug 132255 tests this. In fact, this is just a duplicate of bug 132255.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.