123140 - URL changes to "wyciwyg://0//" and sometimes shows a blank page.

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P3)

Description

[Sören 'Chucker' Kuklau (gone)]

I was surfing around on several sites, then went to http://dniguild.com/ ,
switched to another app and back, and then the URL was changed to
"wyciwyg://0//". Dniguild.com did not load until I clicked the back button,
which also reverted the URL.

Steps to reproduce:
1. Go to http://dniguild.com/
2. Go to any other app.
3. Go back to the Mozilla window with the appropriate tab.
4. Note how the URL has changed to "wyciwyg://0//".
5. Go back; now the URL gets reverted to http://dniguild.com/ and DniGuild.com
is loading.

Expected Results: DniGuild.com should be loaded immediately.
Actual Results: A blank page with the URL "wyciwyg://0//" is loading. Pressing
back causes the desired page to load.

Reproducable: Apparently rarely. Was not able to reproduce it so far.

hwaara said on IRC that the URL was something the Necko team was working on
which shouldn't be visible externally.

Comment 1

[R.K.Aa.]

likely related to the recent fix for bug 35340

Comment 2

[Boris Zbarsky [:bzbarsky]]

radha, any ideas on why this may be coming up?

Comment 3

[guivho]

This also appears when I want to go to http://windowsupdate.microsoft.com
It shows a blank page and the url changes to wyciwyg://0//
This happens consistently whenever I want to go to that url (I first thought it
was an inside joke:).
This with the Feb1 mozilla-win32-installer-sea.exe build on a win2k box.

Comment 4

[Sören 'Chucker' Kuklau (gone)]

Indeed, windowsupdate shows the same problem to me too. But as it doesn't work
anyways under moz (at least not its version 4.0 / XP), that doesn't really
matter much.

2002-02-02-02 (heh) / Win32, MathML/SVG build.

Comment 5

[Radha on family leave (not reading bugmail)]

This is related to the implementation of wyciwyg protocol checked in last week.
 wyciwyg stands for "What you cache is what you get".  It is used to display
pages created dynamically using Javascript  document.write(). If a page appears
blank, it is probably because the page has something that works *well*  only in
IE. That is the case with http://windowsupdate.microsoft.com. The page showing
blank has nothing to do with wyciwyg.  The appearance of wyciwyg on teh urlbar
indicates that there is probably a  document.write() in the site. 

Comment 6

[John Levon]

This happens sporadically for me with :

http://www.geocities.com/anni3/bits/wrong.html

on linux (though the url was longer than that, and it came
in a new window)

checkout finish: Mon Feb 4 19:15:33 GMT 2002

Comment 7

[Matthias Versen [:Matti]]

confirming with win2k build 20020205..
I saw this at www.setigermany.de (forum

Comment 8

[Daniel Mario Vega (Restore MNG Support --> #18574)]

I see this problem when in http://webmail.fibertel.com.ar/
Go there and try to login with any username and password
BuildID: 2002020409 on WinNT

Comment 9

[neeti]

darin, radha: who would be the appropriate person to look at this bug?

Comment 10

[Radha on family leave (not reading bugmail)]

Its mine. 

Comment 11

[Radha on family leave (not reading bugmail)]

I don't see any problem with dniguild.com.  As I explained before, wyciwyg:// is
a new protocol used to represent JS  based dynamic pages. If you see a blank
page, it is most probably because the page has content that doesn't render well
in mozilla and therefore a layout issue. After you load a page, if the urlbar
changes to wyciwyg://, its  probably because the page has a dynamic script that
is triggered from a onLoadHandler or a timer or Meta refresh etc ... This is not
a misbehavior.  It is a feature.  You may not have seen this behavior (urlbar
changing) before because the protocol didn't exist before. 

Comment 12

[Matthias Versen [:Matti]]

bah,I want the URL in the URL Bar and not this stupid "wyciwyg://0//"....

You said: "It is a feature" but i say that this is a bad feature and it looks 
like a bug...

Comment 13

[John Levon]

If the problem lies in the sites' code, why isn't this an evang bug ?

It seems to me that this has just been incompletely analysed (aka: brushed
off). 

Comment 14

[Sören 'Chucker' Kuklau (gone)]

So for what do we have quirks mode then? We *should* be able to render sites
with improper HTML. That's what quirks mode is for. And those *shouldn't*
redirect Mozilla to wyciwyg://0// (this _is_ a recent Mozilla bug because it
never happened before and doesn't happen in other browsers either. And it simply
shouldn't happen because it will confuse users.)

Comment 15

[Sören 'Chucker' Kuklau (gone)]

It happened again - I went to the URL, it partly loaded, then I got redirected
to wyciwyg://0//. I went back, and then the URL fully loaded. This can't
seriously be "WONTFIX".

Comment 16

[Boris Zbarsky [:bzbarsky]]

Reopening.  The problem here is that an internal implementation detail (the
wyciwyg protocol) is being exposed to the users in an unnecessary and confusing
way. Blank page problems should get separate bugs; they are unrelated to the
issue at hand.

Why does the url change?  Shouldn't wyciwyg stuff set the URI on the channel,
not the originalURI?

Comment 17

[Blake Ross]

This can't be wontfix...this exposes our backend to the user which is
ridiculous; it breaks bookmarks and internet shortcuts; and it just doesn't make
any sense.  Nominating for machv, I don't believe we would ship with something
like this.

Comment 18

[Radha on family leave (not reading bugmail)]

whoever can reproduce the blank page  on dniguild.com, please provide a build
id, platform etc ... The blank page is not a wyciwyg problem, please open a bug
on evengelism or layout for the blank page issue. 

Comment 19

[Sören 'Chucker' Kuklau (gone)]

Can _sometimes_ reproduce this on 2002-02-08-00, Win32, MathML/SVG.

I was pretty certain that the blank page is related to wyciwyg, since
dniguild.com always worked fine (for months) _before_ I first even heard the
name "wyciwyg".

Comment 20

[bht237]

There is a testcase in bug 125003. The "wyciwyg" garbage is not limited to the
URL bar. In fact URLs that are definitely http:// get their values corrupted in
such a way that breaks JavaScript based navigation.

Comment 21

[Boris Zbarsky [:bzbarsky]]

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

Comment 22

[Boris Zbarsky [:bzbarsky]]

Bug 125003 has a testcase that reproduces this problem 100% of the time for me.

Comment 23

[Jeremy M. Dolan]

nominating for 0.9.9, as a fix is likely to cause severe regressions (for
example, wyciwyg already broke referer)

Comment 24

[Radha on family leave (not reading bugmail)]

In the testcase attached to bug 125003, after clicking on "Open new window", the
new window comes up with a "wyciwyg://0/..." url indicating that the page being
viewed was created due to a document.write(). When the timer goes off and the
new url loads, the urlbar promptly changes to the new page.  I tried the
testcase with a build prior to wyciwyg implementation. In that case, the new
window comes up with an empty urlbar,  and then changes to the new location
after the timer goes off.  The difference between the 2 versions are,

1) In the older build, the new page
"http://bugzilla.mozilla.org/attachment.cgi?id=69026&action=view" opened in the
new window, does not get added to session history.  If you go somewhere else 
from that page, you can not do back/forward/Go to it.  In the newer build, this
page is added to session history and you can do back/forward/go to it. That is
the whole purpose of that protocol. See bug 35340 for more details. 

I think the primary problem here is, users are not used to seeing a "wyciwyg" in
the urlbar. This feature has  never been there in NS 6.x. NS 4.x has it and you
can sometimes see a "wysiwyg" instead of a "wyciwyg" (What You Cache Is What You
Get)in the urlbar. NS 4.x may not always show a "wysiwyg" for all
document.write(), because its implementation is buggy too. Inspite of having the
wysiwyg protocol implementation, NS 4.x shows some misbehaviors with
back/forward/Go menu. 

Comment 25

[Blake Ross]

Can't we have our cake and eat it too?  It seems weird to me that in order to
get the session history goodness, we must expose wyciwyg protocols to the user.
 The backend doesn't care about the value in the urlbar, so surely there must be
a way to show the proper url there.  Aside from being confusing, as has been
stated here, it breaks other things.  Radha, I can't tell if you're defending
the current behavior or simply summarizing what this report deals with (if the
latter, I agree with you).

Comment 26

[bht237]

What bug 125003 tries to demonstrate is different from this bug of different
from what some think this bug is about.

Sure you see the wyciwyg in the URL bar of the new window of bug 125003.

But:
The issue is that the wyciwyg pseudo URL is sometimes NOT cleared even after the
onload event of the new document (the script proves this, our eyes may not be
fast enough).

The more obvious issue of having a wyciwyg URL in the location bar of a 100%
dynamically written document is not a problem IMHO. It is 100% consistent
behavior, only cosmetic.
There cannot be any navigation error in this case because a 100% dynamically
written page does not exist on the network and bookmarking etc would fail anyway.

Comment 27

[John Levon]

bht: thank you, that's explained exactly why this bug needs fixing.

It is not bookmarkable. It is not meaningful to the user. It has absolutely
zero useful information content to the user. So: why do you think it should be
shown ?

Comment 28

[Radha on family leave (not reading bugmail)]

>But:
>The issue is that the wyciwyg pseudo URL is sometimes NOT cleared even after the
>onload event of the new document (the script proves this, our eyes may not be
>fast enough).

I don't see what you are saying here. In the script, after the new window comes
up, the "wyciwyg://.." shows up on the urlbar momentarily until the new page is
loaded. When the new page is loaded, its url
"http://bugzilla.mozilla.org/attachment.cgi?id=69026&action=view" shows up in
the urlbar. "wyciwyg;//" doesn't hang around  anymore. 


You can bookmark a wyciwyg url, just like you can go back/forward to it. That's
exactly what that protocol does. It stores the content of  all the
document.write(), in the example case, '<BODY bgcolor=black
text=white><CENTER><BR>Please wait :)' in cache and restores it back whenever
the  user tries to access it again either through  session history mechanisms,
or by pressing enter in the urlbar or by bookmarking it. 

Comment 29

[Radha on family leave (not reading bugmail)]

blaker: as far as, eating the cake too, it may be difficult. Browser updates the
back/forward buttons and the urlbar in one shot in its
nsIWebProgressListener::OnLocationChange().  It is imperative to update the back
forward buttons. I can look in to making the url of a wyciwyg page the same as
the page that generates it. There could be technical issues with cache regarding
that. In that way no one will notice when the url changes. 

Comment 30

[bht237]

[e-mail],

I did not mean to say what you understood.

I don't mind that there is a "wyciwyg://.." URL in the URL bar.
In fact it is 100% correct to have it for 100% generated pages.
If a web author/designer writes a generated page into a HTML frame then the URL 
should not be shown in the URL bar, only the URL of the top window 
should be shown.
If the designer generates content in a new window e.g. popup then they 
should open the popup without URL bar.

The URL http://bugzilla.mozilla.org/showattachment.cgi?attach_id=69027
is being misinterpreted.

What you see (at the first glance) with this URL is 100% correct and 
shows no more than that "wyciwyg://.." exists.

However if loaded onto a local web server, a situation arises where 
AFTER a static web page is loaded, the old "wyciwyg://.." URL is still 
in there. Only THAT is what I called "garbage".

The "wyciwyg://.." URL is in fact a good thing because on the client 
computer, it allows the user to cache and view later generated pages 
which is not possible otherwise.

I think Mozilla should NOT try to please those who prefer to have a 
fake http:// URL in the location bar instead of "wyciwyg://.." if in fact that
would be a lie 
because the page does not have a file on the network.

Comment 31

[bht237]

[e-mail],

bug 125003 is on a deeper level.

It is a transient, racing condition type of issue and I am not sure 
whether many have even seen it. It is for this reason that I do NOT 
think that bug 125003 is a duplicate of this.

As I said before, I do NOT argue about the usefulness of the "wyciwyg://.."
protocol/URL since you explained this sufficiently, and thanks for 
that. I see that the "wyciwyg://.." has a very high value and IMHO, overpainting
its correct consequences for cosmetic reasons creates more problems of
incorrectness than it solves.

BTW I would not want to exclude that some effects seen on some sites are caused
by bug 125003. I would suggest to fix bug 125003 with highest priority.
In comparison I think that showing "wyciwyg://.." where appropriate is not a bug
at all. It's correct. How would I otherwise be able to retrieve such a page from
history ????? It's local and may contain localised data etc.

Comment 32

[Radha on family leave (not reading bugmail)]

[e-mail] : The urlbar will change to the "wyciwyg://" url only if the
document.write() is done on  _top. If  document.write() happens on a subframe,
back and forward buttons will update accordingly, but not the urlbar. If you see
a situation where a document.write() in a subframe leads to a change in the
urlbar, let me know. That is a bug. 

>The URL http://bugzilla.mozilla.org/showattachment.cgi?attach_id=69027
>is being misinterpreted.

I don't understand what you mean by misinterpreted. In the testcase,  when the
new window pops up,  and loads "please wait :)", that is purely a result of a
document.write() and the new window knows nothing about the impending timer.
Here, the timer runs in the parent window. When the timer kicks in and does a
location.replace, the urlbar automatically changes to the new url, erasing
wyciwyg from the urlbar. 

Comment 33

[Matthias Versen [:Matti]]

A User doesn't know what "wyciwyg://0//" is and a user doesn't want it in the 
URL Bar.
It makes no sense for a user to see "wyciwyg://0//" because it's confusing.
(why should I see it ?)

I see this problem sometimes with the JS Frame on www.setigermany.de (btw: there 
is another bug about this menu because mozilla destroys it..) and no other 
Browsers shows it there (NS4.78DE and IE5.01) !

Comment 34

[Hixie (not reading bugmail)]

This could maybe be solved in much the same way as we fixed about:blank (or a
generalisation of that solution maybe).

Comment 35

[Radha on family leave (not reading bugmail)]

Ian: You mean not updating the urlbar if the url is 'about:blank'.

Comment 36

[John Levon]

OK, I misunderstood. So there are some cases where the URL stays - fine.

At the very least, can you make it say something vaguely meaningful like :

cached://

or somesuch ?

Comment 37

[bht237]

[e-mail],
The misinterpretation becomes obvious when reading the 2 source files of the
testcase in bug bug 125003. There is a comment inside.

The timer loads a HTML file from the network.
The file contains an onLoad event that displays its own URL.
The bug is that AFTER the onLoad event, where it should print the URL as HTTP://
or at least not "wyciwyg://", it prints a corrupted URL string containing
"wyciwyg://".

Should a URL of a simple file loaded from the network ever contain "wyciwyg://"
after its own onload event?

The way that http://bugzilla.mozilla.org/showattachment.cgi?attach_id=69027 is
used in this bug is by only using a subset of what it is trying to show.
And as I already noted in bug 125003, bug 125003 does not reproduce its error
when loaded from bugzilla. For me the bug only shows if I alter the files and
load them from a local web server.

I am strongly suggesting to separate these 2 bugs and to re-open bug 125003,
because it is much narrower in scope than this but it is more dangerous because
it shows clear evidence of corruption.
At least it breaks some commercial web applications that I am maintaining.

Comment 38

[Alfonso Martinez]

About comment http://bugzilla.mozilla.org/show_bug.cgi?id=123140#c32:

I filed bug 125225 to show how the url can change by using document.write in an
iframe.

Comment 39

[Radha on family leave (not reading bugmail)]

I will be attending to bugs 125003 and bug 125225  during the mozilla 1.0 cycle,
after I take care of my nsbeta1+ nominations. I will keep this bug open to
investigate the  _sometimes_ reproducible blank page in www.dniguild.com. 
However, I don't believe that this bug warrants a nsbeta1 nomination. 

Comment 40

[Susie Wyshak]

Please see my last comment in http://bugzilla.mozilla.org/show_bug.cgi?id=98654
(Blank Yahoo pop up ads) 
If that issue seems to be related to this bug please mark as a dupe -- and leave
the nsbeta1 on this bug if that's the case. Thanks!

Comment 41

[Radha on family leave (not reading bugmail)]

Looking thro' 98654, it looks like document.write() can sometimes lead to blank
pages.  If that is the case, this bug should be a dupe of that.  The wyciwyg
implementation just gave a  protocol identification to  document.write() and
does not affect the behavior of document.write() in any way. 

Comment 42

[bht237]

Attachment: blank page

Comment 43

[bht237]

Attachment: Testcase start HTML

Testcase shows that both the URL bar and JavaScript top.location are corrupted
by document.write() into a child frame.

Comment 44

[bht237]

What does this mean: nsbeta1- ("This keyword will be added to bugs which the
Netscape evaluation team has rejected for the next Netscape release.") ?

Does it mean that 

a) the bug will be rejected by the developers i.e. not fixed before Netscape release

or

b) that the Netscape evaluation team rejects this bug i.e. it will not release
Netscape before this bug is fixed?

Comment 45

[Boris Zbarsky [:bzbarsky]]

It means that Netscape developers will most likely not work on the bug until the
next netscape release (unless they want to do so on their own time).  What
non-Netscape developers do is, of course, their own business.

Comment 46

[bht237]

[e-mail], many thanks for the explanation.

Does this mean that there is a chance that this bug will be in the next Netscape
release?

That would mean that frames sites that use a simple location.replace() in a
subframe will have their top frame URL set to "wyciwyg://0//".

I cannot imagine that Netscape would want to release anything like this. There
must be a misunderstanding somewhere. Someone please help me.

Comment 47

[timeless]

sure, heck, this bug could be in the next 20 netscape releases. you need to be 
more imaginative.  

brendan: this is extremely ugly. I think it breaks things. And, I haven't heard 
a good reason not to back it out (or even a good explanation for why we wanted 
it in the first place).

For reference, the last disaster (that comes to mind, anyways) that netscape 
landed was full screen mode which was backed out because the engineers didn't 
have time to fix it right.   A correct fullscreen mode actually landed last 
night, so apparently some netscape engineers had better free time.

Comment 48

[Boris Zbarsky [:bzbarsky]]

Good reasons I can think off offhand why we want this stuff:

1)  Correct back/forward navigation of pages created via document.write()
2)  View source of pages created via document.write() (Try it.  It works.)

Comment 49

[bht237]

Boris, I agree with you.
At some stage I would definitely also want these features.

But users will be more disappointed when they cannot bookmark domain home pages.
As the testcase clearly demonstrates.

I am still confident that Mozilla/Netscape will make the right decision in view
of the facts, i.e. backout or fix this and the even more severe bug 125003.

If not, then we would have a major Quality Assurance disaster.
Does Mozilla need one? I don't think so.

Comment 50

[Brendan Eich [:brendan]]

I perpetrated wysiwyg (note s, not c) in Netscape 3.0 to solve the problem, and
wyciwyg is my red-headed stepchild.  Netscape 3 and 4 tried very hard to censor
wysiwyg://... prefixes from user-visible URLs, and failed too often -- but it at
least tried.

In no case should the user see these URLs in the URL bar; every case where you
might see such an URL is a bug, I claim.  If that's what this bug is about, I'm
all for fixing it ASAP.  I'd be surprised if netscape.com would want it in any
product.

Assuming the problem is visibility of wyciwyg://... prefixes, this bug may not
be well-assigned.  Who should censor them?  If they follow the wysiwyg: design,
you can simply strip the URL scheme and host part.

/be

Comment 51

[bht237]

Brendan,
There are 2 issues here:

1) Very bad bug
The location data i.e. URL and the JavaScript location object of an ordinary top
level framesetter (loaded from the network and NOT generated) is actually
getting corrupted. Please refer to the testcase.

2) Confusion
There might be pages on the web somewhere that are fully generated and show
wyciwyg in the URL bar. Why not, that's 100% correct, an issue of bad web page
design and acceptable IMHO.
In fact I think that some 1) type of cases are incorrectly identified as 2) type
of cases.

Comment 52

[Brendan Eich [:brendan]]

bht: re (2), I do not agree that "bad web page design" is the cause of
wyciwyg://... showing up in Mozilla's URL bar.  The pages where this occurs that
do not use IE-only JScript/DHTML magic work fine in other browsers, including
4.x, right?  The problem is Mozilla's for disclosing an irrelevant, non-standard
URI scheme implementation detail.  wyciwyg://... (the scheme and host parts)
should be stripped from all presentations.

/be

Comment 53

[bht237]

Would someone please remove "[testcase in bug 125003]" from the Status
Whiteboard field.
This bug has its own testcase - the one that I am usually referring to.

Comment 54

[bht237]

Brendan,
re 2) I don't really have a strong opinion. If that wyciwyg is stripped from the
URL bar then that's better than not. I only wanted to separate the issues so
that the more dangerous and more prevalent issue 1) gets the attention it deserves.

Comment 55

[timeless]

brendan: pike reports that they don't include scheme.

<Pike> rayw: I get a 
<Pike> Error loading URL file:///tmp/mozilla/extensions/xmlextras/tests/null : 804b0002
<Pike> Document wyciwyg://0//tmp/mozilla/extensions/xmlextras/tests/soapheadlinenews.html loaded successfully

as for who could/should do stripping, i'd ask adam lock.

Comment 56

[gavin long]

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

Comment 57

[Brendan Eich [:brendan]]

wyciwyg: must transform the URL in a way that allows one to recover the original
URL, as wysiwyg: did in Mozilla classic.  The easiest way to do this is to
prefix unambiguously.  This needs to be fixed in 0.9.9 or 1.0.  Radha, do you
need help or can you change to an unambiguous prefix that preserves the original
URL's scheme?

/be

Comment 58

[Radha on family leave (not reading bugmail)]

I'm planning to keep the original url for the wyciwyg urls too, since as you
mentioned it is a non-standard protocol.  Nav 4.x sometimes shows a wysiwyg://
on the urlbar and sometimes doesn't. I don't know what the logic  was in 4.x
w.r.t showing wysiwyg:// on the urlbar. I hope that's ok with everyone. I do
want to address this for 1.0 and I will be able to do it. 

Comment 59

[Davide Bolcioni]

Greetings,
  I have a wild suggestion. Instead of "wyciwyg:", you might find acceptable to
use "written-by:<original-scheme>[/<id>]:<original-url>", which would fit the
RFC 2396 syntax (look for opaque_part) for URI but not for URLS (which is good,
as this is a thing which has no location), and would be sort of readable to the
user. It is a bit long, but maybe some native English speaker can come up with
something shorter. It also cascades, e.g. you can have
"written-by:written-by:http://...". The <id> I am afraid would be necessary in
the case the same url-endowed page writes to multiple places, and I would really
like a way  to stick it or its equivalent at the end instead.

Comment 60

[Brendan Eich [:brendan]]

Any time 4.x shows wysiwyg://... in the URL bar, you're seeing a bug that we
should strive not to recapitulate in Mozilla.

/be

Comment 61

[Radha on family leave (not reading bugmail)]

This will be fixed for 1.0 as  targeted.

Comment 62

[Radha on family leave (not reading bugmail)]

Attachment: Patch to eliminate wyciwyg from the urlbar.

The patch only takes care of wyciwyg showing up on urlbar. It does not take
care of any blank page that may be associated with document.write()s.

Comment 63

[Johnny Stenback (:jst)]

Comment on attachment 71764 [details] [diff] [review]
Patch to eliminate wyciwyg from the urlbar. 

>+        // Check if the url has a "wyciwyg://" protocol string. If so,
>+        // remove it from the url so that it doesn't show up on urlbar.  
>+        var wc_pos = location.search(/wyciwyg:\/\/\d+\//);

Make that regexp start with ^ to avoid having to search through the whole
string looking for wyciwyg, or is there an even faster way in JS to do this?

sr=jst with that fixed.

Comment 64

[Bob Clary [:bc] (inactive)]

If all you care about is if wyciwyg: occurs at the beginning of the string,
wouldn't indexOf be faster?

Comment 65

[Mike Shaver (:shaver emeritus)]

The regexp also checks for a following number, but it's not clear that we really
care about malformed wyciwyg URLs.

Comment 66

[Brendan Eich [:brendan]]

The regexp should begin with ^ to anchor to front of string (assuming spaces
have already been stripped -- have they?  if not, use /^\s*wyciwyg:\/\/\d+\//
instead).  An anchored regexp will beat indexOf, which would again search the
whole string in the miss case.

/be

Comment 67

[bht237]

Radha, what is the result of the testcase
http://bugzilla.mozilla.org/attachment.cgi?id=69640&action=view
saying for you after the application of the patch? Failure or success?

Comment 68

[Mike Shaver (:shaver emeritus)]

Brendan explained to me that we do need to look for the number.  I was confused
by the fact that we were using search, rather than replace, but are looking to
strip the prefix.  Sorry, I should have been reading more carefully.

Comment 69

[Brendan Eich [:brendan]]

Now that shaver mentions it, it's odd to use .search when you really just want
to test for match.  To do that with least overhead, use regexp.match(target),
not target.search(regexp) == 0 for an anchored-at-front regexp.

So, here's my best advice for now:

        if (/^\s*wyciwyg:\/\/\d+\//.test(location))
          location = RegExp.rightContext;

But again, if you know that location has had trailing and leading space
stripped, then you don't need the \s*.

/be

Comment 70

[Brendan Eich [:brendan]]

Argh, typing too fast: in

>to test for match.  To do that with least overhead, use regexp.match(target),

I obviously meant "... use regexp.test(target)," as the code sketch immediately
after said.

/be

Comment 71

[Radha on family leave (not reading bugmail)]

Attachment: Updated patch per Brendan's suggestion.

It turns out that we don't really strip out spaces on all cases. So check for
spaces stays.

Comment 72

[Alec Flett]

Comment on attachment 71985 [details] [diff] [review]
Updated patch per Brendan's suggestion.

I can't let this go without requesting that you fix some of the WithConversion
stuff 
(I know it isn't directly part of the patch, but the previous code should never
 have gone in as-is)


>+
>   // Generate the wyciwyg url
>   url.AssignWithConversion( "wyciwyg://" );

url.Assign(NS_LITERAL_STRING("wyciwyg://");

>   url.AppendInt(mWyciwygSessionCnt++, 10);
>   url.AppendWithConversion("/");
url.Append(PRUnichar('/');

>-  url.AppendWithConversion(urlPart);
>+  url.AppendWithConversion(originalSpec);

specs are UTF8:
url.Append(NS_ConverterUTF8toUCS2(originalSpec));

Comment 73

[Chris McAfee]

r=mcafee for Brendan-patch

Comment 74

[Chris McAfee]

Comment on attachment 71985 [details] [diff] [review]
Updated patch per Brendan's suggestion.

r=mcafee, make sure it works & stuff! :-)

Comment 75

[Brendan Eich [:brendan]]

Yeah, what alecf said -- my review was limited to the JS regexp stuff.

/be

Comment 76

[Radha on family leave (not reading bugmail)]

Attachment: updated per alec's suggestion.

Comment 77

[Alec Flett]

Comment on attachment 72081 [details] [diff] [review]
updated per alec's suggestion.

thanks for fixing that.. actually the NS_LITERAL_STRING("/") could really be
PRUnichar('/') like I suggested above, but sr=alecf on this patch.

Comment 78

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is this patch ready for the trunk and 0.9.9 branch? Is rahda ready to ask for
approval?

Comment 79

[Asa Dotzler [:asa]]

Comment on attachment 72081 [details] [diff] [review]
updated per alec's suggestion.

a=asa (on behalf of drivers) for checkin to the 0.9.9 branch and the 1.0 trunk.

Comment 80

[bht237]

Attachment: file 2 of new testcase

Comment 81

[bht237]

Attachment: Start HTML of testcase 2

With the latest 0.9.9 build 2002030116 I still get wyciwyg URLs.
Please refer to testcase 2 for an example.
My apologies that the first testcase did not catch this.
Good luck!

Comment 82

[Radha on family leave (not reading bugmail)]

bht: I have not yet checked in this patch.  Do you see  the problem with the
patch?  

Comment 83

[bht237]

Radha,
I can't apply patches because I can't compile. I worked with the binary build as
downloaded. With that, testcase 1 did not reproduce anymore so I wrote testcase 2.
What are the alert boxes of testcase 1 and testcase 2 showing when you run them
on a patched build? I need to know this otherwise I am working my butt off and I
am not getting anywhere.
I might need to write yet another testcase because the problem appears to be
rather nasty. I hope that a binary build with the patch is available soon so
that I can test real sites.
Otherwise I need your feedback from these testcases - so far I haven't got it :(

Comment 84

[Radha on family leave (not reading bugmail)]

bht: In testcase 1, the dialog says, "URLs mach. testcase pass".
In testcase 2, the dialog says. "URLs don't match. Test case failed".

I think that in testcase 2 you are trying to show that a  doc.write in a
subframe affects the url of the _top. Bug 125225 addresses that issue. I am not
working on that bug yet.

Also, I would want you to know that, the patch attached to this bug, *only*
prevents wyciwyg:// from showing up in the urlbar. It does not change the actual
url of the dynamic page. So, if you loaded a simple doc.write() page on _top and
did a top.location.href on it, it will show the url to be "wyciwyg://....", even
though wyciwyg:// does not appear on urlbar.

Comment 85

[Asa Dotzler [:asa]]

Radha, can you check this in today? Thanks.

Comment 86

[Radha on family leave (not reading bugmail)]

This was fixed yesterday in the trunk and branch. 

Comment 87

[benc]

-> history:session.
QA to claudius.
I'm 90% sure this is not for me to qa. So I'm sending it where the other bugs went.

Neeti, you need to re-assign qa when you assign a bug to a non-necko engineer.
Radah, you need to check your bugs for your qa person. I'm sure cladius would
have had something to say.
---

I object to creating glib and obscure scheme names. Rather than morph this bug,
I reference bug 130089, and continue to wish that a standards compliant browser
would release 1.0 w/ standards compliance is the easiest of areas: naming
something you invented yourself.

Comment 88

[Susie Wyshak]

Are you suggesting this to be reopened? It really needs to be fixed in 1.0 as now
I'm seeing it on a very prominant partner site - wyciwyg://0/http://www.nfl.com/

Not sure if once bug 98654 is fixed (which also affects nfl.com) if the wyciwyg
problem will go away...

Comment 89

[sairuh (rarely reading bugmail)]

looks fixed with 2003.02.19 comm trunk on linux rh8.0.