222157 - View Source: Save as doesn't work (Find, Find Again have been fixed)

Status: RESOLVED FIXED

(Toolkit :: View Source, defect, P4)

Description

[Ed Hume]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031014 Firebird/0.7+ (aebrahim)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031014 Firebird/0.7+ (aebrahim)

In 'View Source' cannot get Find to work, either with ctrl-f or with dropdown menu.

Reproducible: Always

Steps to Reproduce:
1. Open View Source
2. Select Edit > Find (or simply press ctrl-f)
or Select Edit > Find Again (or press ctrl-g)

Actual Results:  
Nothing happens

Expected Results:  
Open Find dialog

Works as expected in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a)
Gecko/20031014.

Comment 1

[Steffen Wilberg]

Save As and Print are broken as well, they're greyed out.
Pierre mentioned all this in bug 221668 comment 21.
Adding regression keyword.
Pierre, if you intend to reopen bug 221668, this one would be dupe.

Comment 2

[Alan Williamson]

The VIEW SOURCE functionality has also completely died on my machine.  That
said, it was broken in the previous release *after* i installed a given
extension.  I only have a handful of extensions.  The one i believe is causing
grief is when i tried to remove the NEWSMONSTER one.

Comment 3

[Jon Henry]

Is View Source still completely broken in recent nightlies? For a week or so it
broke (after doing View Source, the window would simply not appear on subsequent
attempts and Mozilla would not completely shut down; you had to kill the process
in Task Manager), but that has since been fixed.

Comment 4

[Pierre Chanial]

-> me
I'll fix sometimes soon, but I want to fix it the proper way ie by fixing the
bogus dependencies.

Comment 5

[Pierre Chanial]

I just hooked up page setup and print functionalities.
However I don't have a printer handy.
So your feedback will be really appreciated!

Comment 6

[Christian Reis]

Printer?

Comment 7

[Bill Gianopoulos [:WG9s]]

OK I was able to print successfully from a view source, but in a font size
smaller than I find easily readable and there did not appear to be a way to
change the printer font-size in the page setup.

However, Edit-> Find still does not work and I find this a much more serious
issue than printing.  For the few times I want to print from a view source,
doing a select all and copy/paste into notepad would suffice.  That is way too
inconvenient for the number of times I want to do a find from a view source
(which is about 100% of the time).

Comment 8

[Bill Gianopoulos [:WG9s]]

There are issues with printing.

1.  Wide lines appear to make it chose a ridiculously small font. if you have
shrink width to fit page turned on.

2.  Even with shrink width to fit page turned on it seems to truncate long lines.

I think an option like "Wrap lines at xx columns for printing" needs to be added
to page setup to fix this.  It should also be possible to select a font size for
printing.

Comment 9

[Hussam Al-Tayeb]

Printing now works, but the find and save functions still don't.

Comment 10

[Simon Paquet [:sipaq]]

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

Comment 11

[Simon Paquet [:sipaq]]

Adjusting summary.

Comment 12

[Simon Paquet [:sipaq]]

This is essentially an old bug (bug 205815). Since Pierre is actively working on
this one here, I'm duping the older bug against this one.

Comment 13

[Simon Paquet [:sipaq]]

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

Comment 14

[Simon Paquet [:sipaq]]

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

Comment 15

[Simon Paquet [:sipaq]]

.

Comment 16

[Scott Gifford]

I see this bug on Linux too, with 20031101.  --> All/All.

Comment 17

[Ben Goodger (use ben at mozilla dot org for email)]

If you don't want this pierre reassign to me. 

Comment 18

[Pierre Chanial]

Ben: I've just cut the last comm.jar dependencies in the toolkit.
Now, it's time for me to work on that.

Comment 19

[Bill Mason]

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

Comment 20

[Jesse Ruderman]

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

Comment 21

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031114
Firebird/0.7+(zip/installer)
The following shows in source after
  View Selection Source
is used:

%u200B%u200B%u200B%u200B%u200Bselection of text%u200B%u200B%u200B%u200B%u200B

I did not notice this behaviour before.
The selection of text is NOT highlighted

 

Comment 22

[alanjstr]

This is not about View Selection Source not showing the right text.

Comment 23

[Bill Mason]

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

Comment 24

[Pierre Chanial]

Thanks for the patience, everybody!
find in page is fixed. 

Comment 25

[Matthew van Eerde]

I suggest delegating the "View Source" editor to the OS, a la IE/Win -
development time can probably be better spent than on maintaining what is
fundamentally a text viewer.

View Source only makes sense for text/html pages, right?  If I'm looking at a
.jpg, I don't need to View Source.

Comment 26

[alanjstr]

Matthew:  That has absolutely nothing to do with this bug.  Of course View
Source only applies to text.

Marking fixed per Pierre's comment.  As soon as a Win32 build gets released
again I can verify.

Comment 27

[Peter van der Woude [:Peter6]]

it applies to SVG aswell

Comment 28

[Bill Gianopoulos [:WG9s]]

Re; comment #26, If you actually read Pierre's comment, this does NOT fix the
Save as issue.  This bug needs to now be reopened, but I don't have sufficient
authority to do that.:-(

Comment 29

[Steffen Wilberg]

Thanks for fixing Find and Find Again. Works fine.
Reopening and changing summary for Save Page As.
Old summary was "View Source: Save as, Find and Find Again don't work".

Comment 30

[Jacek Piskozub]

Steffen: Bug morphs like this make QA work difficult as it is virtually
impossible to find the original bug to dupe any new reports against :-(

Comment 31

[Michael Lefevre]

Indeed. Reverting summary...

Comment 32

[Paul Dorneanu]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031123
Firebird/0.7+

installer nightbuild... still doesn't work. for me too.

Comment 33

[Steve Wardell]

spooky: Can you clarify exactly what does not work in that build. The Find /
Find Again is supposed to be fixed by Save As is still an open issue. Is that
consistent with what you are finding?

Comment 34

[José Jeria]

Same problem here, with Gecko/20031122 Firebird/0.7+, windows xp. Find doest 
work. nothing gets selected. Using the installer build.

Comment 35

[Pierre Chanial]

José, Steve, Paul: this bug is specific to viewsource. What you're seeing is bug
225530. If the "find in page" feature works in your build, it will work in the
browser and the viewsource. If it doesn't, it won't work anywhere.

Comment 36

[alanjstr]

Also, please verify with an unzipped build, not just an installer, to make sure
it is not an installer problem.

Comment 37

[Peter van der Woude [:Peter6]]

I'm using 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031124
Firebird/0.7+ (Nova: SVG,MNG,DOMi,Venkman) - ZIP
and ctrl+F + next and "find as you type" +F3  both work in html/source
try a 20031123 or 20031124 build

Comment 38

[José Jeria]

I downloaded both the zip and the installer, build 20031123. With the zip this
is WFM, with the installer this is broken. I am on Win XP.

Comment 39

[alanjstr]

Installing to a new dir?  new profile?  Installer bugs should be filed seperately.

Comment 40

[José Jeria]

> Installing to a new dir?  new profile?  Installer bugs should be filed seperately.

Yes, did all of the above with the installer build, still seing this problem, so
then, a new bug should be opened for this issue? 

Comment 41

[alanjstr]

Yes, please.  And assign it to the Installer component.

Comment 42

[José Jeria]

bug 226674 was filed for the issues mentioned in comment 38.

Comment 43

[Hussam Al-Tayeb]

So the only thing remaining is the "save as" in the viewsource. Everything else
works here in the zip version.

Comment 44

[Mike Connor [:mconnor]]

updating severity, as this can be saved from the browser window itself, so its
an annoyance more than a major break in functionality without a workaround. 
Also keep in mind that the menu option is disabled, so we're at least not trying
and failing to do it.

also, for what's left, there is not enough justification to block release for a
fix, the menu option is disabled at the current time.  I expect that this will
be fixed for 0.9.

Comment 45

[Ben Goodger (use ben at mozilla dot org for email)]

-> 0.9

Comment 46

[Pierre Chanial]

I re added the mozilla/browser dependency to fix the 'save as' functionality,
but only on the branch.

Comment 47

[Hussam Al-Tayeb]

(In reply to comment #46)
> I re added the mozilla/browser dependency to fix the 'save as' functionality,
> but only on the branch.

Just a question, why isn't this added to the trunk as well? will it cause a
regression of some sort?

Comment 48

[Mike Connor [:mconnor]]

because it introduces an undesirable dependency, and its better to wait on a
real fix instead of doing a band-aid.

Comment 49

[Jordan Callicoat]

Attachment: Fixes Save As functionality

I'm not sure if this is a viable solution (mabye it was just overlooked?) or if
there is some reason why it was not implemented, but all that seems to be
needed to get the Save As functionality working is to include
contentAreaUtils.js from browser/content (saveURL() function is defined there).


Ps. I also wasn't sure if before there was a Save As option in the context menu
as well as the menu item in the File menu, but I was thinking there was, so I
included it at the bottom of the context menu, if I was mistaken just ignore
that portion of the patches.

Comment 50

[Jeff Walden [:Waldo]]

Comment on attachment 144931 [details] [diff] [review]
Fixes Save As functionality

(In reply to comment #49)
> I'm not sure if this is a viable solution (mabye it was just overlooked?)

It's not and wasn't.  Your solution seemed too simple, so I did some Bonsai
querying for Pierre's checkin (Bonsai query below):

http://snipurl.com/browser_dep

Scrolling through the list brought up this diff for Pierre's change:

http://snipurl.com/browser_dep_diff

If you take a look, it's basically the change your patch makes, so obviously
your patch will reintroduce that unwanted dependency.  Therefore, I'm marking
the attachment as obsolete.  The only way this will be truly fixed (a.k.a., not
just hacked on a branch so as to eliminate a regression) is if the appropriate
function is somehow ported over to mozilla/toolkit code.  As for how, that's
something I'd imagine the devs would have issues with, so a simple copy/paste
(if it even worked) would almost certainly be insufficient.

Comment 51

[Jordan Callicoat]

Aye, sorry for the spam, should have checked first.

Comment 52

[Asa Dotzler [:asa]]

not going to block 0.9 on this request to add the save as feature to view source. 

Comment 53

[KUI]

Trying to save this page (without viewing the source) does not work, too.
Same with any ordinary text-file

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8a) Gecko/20040426 Firefox/0.8.0+

Comment 54

[KUI]

Trying to save this page (without viewing the source) does not work, too.
Same with any ordinary text-file

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8a) Gecko/20040426 Firefox/0.8.0+

Comment 55

[KUI]

Trying to save this page (without viewing the source) does not work, too.
Same with any ordinary text-file

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8a) Gecko/20040426 Firefox/0.8.0+

Comment 56

[KUI]

Trying to save this page http://bugzilla.mozilla.org/show_bug.cgi?id=222157
(without viewing the source) does not work, too.
Same with any ordinary text-file

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8a) Gecko/20040426 Firefox/0.8.0+

Comment 57

[Hussam Al-Tayeb]

(In reply to comment #52)
> not going to block 0.9 on this request to add the save as feature to view source. 

Could we a least remove the "save page as" menuitem in viewsource, since it
doesn't do anything?

Comment 58

[Hussam Al-Tayeb]

One question, if this isn't fixed by 0.9, will 0.9 final get the same bandaid
fix that 0.8 got? I would really appreciate any information from the people
concerned on this.

Comment 59

[Mike Connor [:mconnor]]

one or the other will happen by 1.0, not necessarily by 0.9.

Comment 60

[Stefan Pietschmann]

honestly ben,

this one is highly annoying and already has almost 100 votes. 
i would kindly ask you to reconsider it blocking 1.0. Saving the source is vital
for alot of webdevelopers - it's a pain to copy everything and paste it in the
editor, which is what you have to do right now.

If this isn't an important bugfix for a 1.0 i don't know ... :(

Comment 61

[Steve Wardell]

Stefan: Source saving is still available from within the browser by right
clicking or from the File menu. This bug about from the View Source window.
There is an easy workaround by doing it via the browser (before a view source).
While this item should be addressed, it's not critical since there is another
way to achieve the expected behavior.

Comment 62

[Bill Gianopoulos [:WG9s]]

Although it may be true that this is not really an essential function, and one
could argue that just removing the choice from the menu "fixes" it, and one
could further argue that most of those 100 plus votes were about the find in
page not working and not about the save as not working, I think there is another
issue here.

My understanding (and my understaiong could very well be wrong) is that the
reason this bug is not yet fixed is that the function it requires is missing
from the Mozilla Firefox toolkit.

Although this bug probably does not block 1.0,  Wouldn't the fact that a
function that is supposed to be in the toolkit and has not been written block 1.0?

Comment 63

[Mike Connor [:mconnor]]

no.  the toolkit is a shared toolkit for creating applications.  Just because a 
product utilizing the toolkit is reaching a 1.0 release doesn't mean the 
toolkit is complete/perfect.

Thunderbird is at 0.6, Nvu is at 0.2, doesn't mean anything relating to the 
maturity of the toolkit.

Comment 64

[Steffen Wilberg]

So what is the plan? Move contentAreaUtils.js to the toolkit? Large parts of
that are needed for saveURL. And it's referenced by some files in
toolkit/mozapps/downloads as well. Thunderbird needs it as well, but uses the
xpfe version currently.

Doesn't seem like a lot of work. It's 5 References:
http://lxr.mozilla.org/mozilla/search?string=browser%2Fcontent%2FcontentAreaUt
plus viewSource.xul, and 2 bogus comments:
http://lxr.mozilla.org/mozilla/search?string=base%2Fcontent%2FcontentAreaUtils

I can do that, but I'd like to hear if that's the way to go. Mike?

Comment 65

[Steffen Wilberg]

Sorry, the 2 comments I mentioned are not "bogus", because they point to the
source, not the chrome:// location. But they'll have to be fixed anyway.

Comment 66

[Mike Connor [:mconnor]]

that makes sense, might want to check with mscott on that, but it seems like 
the sane thing to do.  I don't think there's any reason it shouldn't be in the 
toolkit instead of browser.

Comment 67

[Steffen Wilberg]

Attachment: move contentAreaUtils.js to toolkit/content; fix Save as

Ok, here's the patch. Save as works fine in View Source.
In View Selection Source, it's still disabled because of this code:

// disable menu items that don't work since the selection is munged and
// the editor doesn't work for MathML
document.getElementById('cmd_savePage').setAttribute('disabled', 'true');

Comment 68

[Steffen Wilberg]

mscott, do you have any objections on moving contentAreaUtils.js to toolkit (so
that we can fix Save as in View Source without making the toolkit dependent on
browser)? See comment 64 for an explanation. Thunderbird doesn't use the browser
version of that file anyway as far as I can see.

Comment 69

[Steffen Wilberg]

Attachment: fix thunderbird as well

Thunderbird uses viewSource.xul, which references contentAreaUtils.js, which
references contentAreaCommands.properties. So we need to move the latter file
to toolkit as well.
There's no need to modify the comment in nsHelperAppDlg.js, since that file
isn't in use anymore, we only use nsHelperAppDlg.js.in.
I've added contentAreaCommands.properties to the patch, but I didn't include
the whole contentAreaUtils.js this time, since that file was modified 5 times
since my last patch. Instead, I modified it in its current location, so the
patch won't bitrot in 48 hours hopefully.
It has to be moved (including cvs log) from mozilla/browser/base/content/ to
mozilla/toolkit/content/ after the patch has been applied.

Comment 70

[Steffen Wilberg]

Comment on attachment 149283 [details] [diff] [review]
fix thunderbird as well

Mike, can you look at this please?
mscott didn't respond yet, but this patch doesn't harm Thunderbird other than
fixing view source and adding two files to the toolkit.
Thunderbird can use these instead of the communicator versions in the future,
but I'd like to leave that to another bug.

Comment 71

[Steffen Wilberg]

Rerequesting blocking1.0 since there's a patch now.

Comment 72

[Mike Connor [:mconnor]]

Comment on attachment 149283 [details] [diff] [review]
fix thunderbird as well

aren't we missing the bit for packing contentAreaUtils.properties into global?

Comment 73

[Steffen Wilberg]

Comment on attachment 149283 [details] [diff] [review]
fix thunderbird as well

> aren't we missing the bit for packing contentAreaUtils.properties into global?
Huh? It's been added to toolkit(=global) here:
>Index: mozilla/toolkit/locale/jar.mn
>===================================================================
>+   locale/en-US/global/contentAreaCommands.properties   (contentAreaCommands.properties)

chrome://global/locale/contentAreaCommands.properties works for me.
"Save Page As" correctly displays these strings.


Sigh, please ignore these lines, they're from bug 207656:
>Index: mozilla/toolkit/components/viewsource/content/viewSource.xul
>@@ -175,4 +176,7 @@
> 
>   </vbox> 
> 
>+  <statusbar id="status-bar" class="chromeclass-status">
>+    <statusbarpanel id="statusbar-line-col" label="" flex="1"/>
>+  </statusbar>

Comment 74

[José Jeria]

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

Comment 75

[Steffen Wilberg]

-> View Source.

Comment 76

[Steffen Wilberg]

-> 1.0beta

Comment 77

[K Chayka]

win32 mozilla nightly build 2004062708, w2k

Is there a reason why this bug seems to be limited to Firefox, since View
Source->Save As is busted in the mozilla package as well (and has been for some
time now)?

This is indeed an annoying bug, especially since picking the Save As menu option
(or ctrl+s) still fires up the Save dialog, then the download progress window,
which then just sits there doing nothing. If this bug is going to be hanging
around for a while longer, can you please at least disable Save As in View
Source? That would make it rather less annoying, methinks.

Comment 78

[Bill Gianopoulos [:WG9s]]

RE comment #77.  If Save as in View source is not working in the Mozilla suite,
that is a different issue than this bug.  This bug is caused by Firefox not
packaging in the Mozilla toolkit routines to do the save as and not yet having
implemented it's own toolkit routines to provide the required functionality.  If
save as is broken in view source in the suite, that should be reported as a
seperate bug.

BTW save as in view source works for me though with the 1.7 release Mozilla suite.

Comment 79

[Michael Lefevre]

re comment 77 - the issue with Mozilla is bug 248964

Comment 80

[Hussam Al-Tayeb]

Why not just remove the greyed out "save page as" menuitem under "view source".
After all, it's "view source" and not "edit source".

Comment 81

[Steffen Wilberg]

Comment on attachment 149283 [details] [diff] [review]
fix thunderbird as well

I need to update this patch.

Comment 82

[Damian Harvey]

Firefox 0.9.3 still cannot "Save Page As" from View Source. This is super
annoying and I have to copy and paste or view the page in IE. Would really
appreciate a fix on this. Can the functionality around this be rolled back to
Firefox 0.8 where it worked?

Comment 83

[amano]

Alright. Firefox 1.0 is coming.

Did someone already decide what to do about the bug?

- Leave it as it is (simply remove the blocking flag)?
- Do Pierre's dirty 0.8 release bandaid, whatever that was (as in comment #46)
- Remove the greyed out menu entry (as suggested in #57)
- Unbitrot and consider (=s/sr/a) Steffen Wilbergs patch presented in comment
#76 an #69)

Anyone?

Comment 84

[Steffen Wilberg]

I think it's too late now for my previous patch.
But I'll make a new band-aid (reintroduce the browser dependency) tomorrow.

Comment 85

[Steffen Wilberg]

Attachment: band-aid for the branch (Firefox and Thunderbird)

This reintroduces the browser dependency Pierre removed almost a year ago
(2003-10-13 22:13). It is basically the same Pierre did on the
FIREBIRD_0_8_BRANCH (checkin 2004-01-24 15:32).

However, this patch also fixes Thunderbird. TB still uses xpfe's
contentAreaUtils.js, so I need to reference utilityOverlay.js as well, which
contains validateFileName(). That function is part of browser's
contentAreaUtils.js, but not xpfe's.

This doesn't fix Selection Source, see comment 67.

Comment 86

[Steffen Wilberg]

Comment on attachment 161005 [details] [diff] [review]
band-aid for the branch (Firefox and Thunderbird)

Works fine on both Firefox and Thunderbird.

Comment 87

[Mike Connor [:mconnor]]

Comment on attachment 161005 [details] [diff] [review]
band-aid for the branch (Firefox and Thunderbird)

kick this to vlad, this one is kinda critical, but check with mscott too

Comment 88

[Asa Dotzler [:asa]]

p4 priority - not a blocker. if a fully reviewed patch materializes, please
nominate for aviary approval. 

Comment 89

[Hussam Al-Tayeb]

For Aviary, I suggest removing/hiding the the grayed out "save page as" menuitem. 

Comment 90

[amano]

If the bandaid patch makes the menuitem functional, there is no need to remove
it. This worked for Firefox 0.8, why not with Firefox 1.0. Hopefully the fix
will not fall off the radar since there is no blocker flag anymore.

Comment 91

[Steffen Wilberg]

Attachment: band-aid, unbitrotted [checked in: comment 94]

Same as before, but applies again.

Comment 92

[Steffen Wilberg]

Comment on attachment 163260 [details] [diff] [review]
band-aid, unbitrotted [checked in: comment 94]

This is basically the same simple band-aid which was used for Firefox 0.8. I'd
really like to get this into 1.0 as well.

Comment 93

[Asa Dotzler [:asa]]

Comment on attachment 163260 [details] [diff] [review]
band-aid, unbitrotted [checked in: comment 94]

a=asa.

Comment 94

[Steffen Wilberg]

I've checked in the band-aid into the branch. So Firefox 1.0 and Thunderbird
0.9/1.0 will be fixed.

I'm leaving this open since I didn't check it into the trunk. We need a real fix
there.

Comment 95

[Bill Gianopoulos [:WG9s]]

I'm running the latest windows tinderbox build and this does NOT appear to be
working.  Save as.. rorm View Source is STILL grayed out.

Comment 96

[Bill Gianopoulos [:WG9s]]

re comment #95.  It appears that the issue was that the clocks are not very well
syncronized on the bonsai, cvs, tinderbox and sweetlou systems.  Although it
appeared the build I downloaded had the fix in it, it eveidently did not.  It
worked fine in the next tinderbox build.

Comment 97

[sairuh (rarely reading bugmail)]

vrfy'd fixed with 2004102609-0.11 (aviary1.0) bits on linux fc2. able to save
from source again.

Comment 98

[John Hanna]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041028
Firefox/1.0RC1

Find and Find Again dont work in this build when you rightclick and view source

Comment 99

[Steffen Wilberg]

> Find and Find Again dont work in this build when you rightclick and view source
Broken since 2004-10-27 16:23, fixed since 2004-10-28 09:56. Wait for today's
builds.
https://bugzilla.mozilla.org/show_bug.cgi?id=264852#c24

Comment 100

[Chris]

re Comment #25  I am hoping to use Firefox instead of MSIE to introduce pupils
to html - so I really want View Source to allow me to edit the html.  The simple
view source - edit - save - refresh cycle is what earlier generations of pupils
have used and it worked well.   It would be even better if editing didn't work
on http: documents but only worked on local files.

Comment 101

[Lars Petersen]

#100 wrote "It would be even better if editing didn't work
on http: documents but only worked on local files."

I disagree, although I don't use this feature, it would be good if editing
worked for local files, and for WebDAV enabled sites.

Comment 102

[Steffen Wilberg]

This bug is not about morphing View Source into an HTML editor. At all. And I'm
quite certain it will never be.

If you want to edit HTML, try Nvu, which is a stand-alone and much improved
version of Mozilla Composer: http://www.nvu.com/

Comment 103

[Michael Lefevre]

This all seems to work for me now in a 20041224 trunk build on Windows 2000.

Comment 104

[sairuh (rarely reading bugmail)]

yes, this also w4m using 2004122807-trunk on linux fc2. although it took some
time for the save-file picker to appear (might be separate issue, since trunk
linux builds now use the gnome file picker).

Comment 105

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041228
Firefox/1.0+

WFM

Comment 106

[Anton van Bohemen]

It works because of the aviary landing. The band aid that was designed for the
1.0 version has been ported to the trunk. The *real* bug has not been fixed yet
though.

Comment 107

[Worcester12345]

(In reply to comment #106)
> It works because of the aviary landing. The band aid that was designed for the
> 1.0 version has been ported to the trunk. The *real* bug has not been fixed yet
> though.

Is there another bug number for that?

Comment 108

[Steffen Wilberg]

Attachment: the real patch: move contentAreaUtils.js to toolkit

This is the real solution for the trunk. It's basically the same as the third
patch in this bug: move contentAreaUtils.js and contentAreaCommands.properties
from browser to toolkit.

The reason is that most of contentAreaUtils.js is needed for saveURL(). And
it's referenced by toolkit/mozapps/downloads/content/downloads.xul. Thunderbird
needs it as well, but uses the xpfe version currently.

I've also enabled Save Page in View Selection Source, which works just fine.
I've also fixed Save Page in Thunderbird's View Source, which was broken
because of bug 220215.

I've added contentAreaCommands.properties to the patch, but I didn't include
the contentAreaUtils.js because that's bitrot-happy. Instead, I modified it in
its current location. It has to be cvs-moved from mozilla/browser/base/content/
to mozilla/toolkit/content/ before the patch can be applied.

Thunderbird neither uses nor ships toolkit's new contentAreaUtils.js yet, but
that's another bug.

Comment 109

[Worcester12345]

Requesting blocking since there is now a patch.

Comment 110

[Mike Connor [:mconnor]]

Comment on attachment 177272 [details] [diff] [review]
the real patch: move contentAreaUtils.js to toolkit

>+  <!-- XPCNativeWrapper.js is needed by xpfe's contentAreaUtils.js (introduced by bug 220215) -->
>+  <script type="application/x-javascript" src="chrome://global/content/XPCNativeWrapper.js"/>

hmm, so why hasn't this broken tbird yet?  Or do they not actually use the
functions in contentAreaUtils.js that depend on this?

We need those changes, but we can do that after the CVS move.

>Index: mozilla/browser/base/content/contentAreaUtils.js
>===================================================================
>RCS file: /cvsroot/mozilla/browser/base/content/contentAreaUtils.js,v
>retrieving revision 1.63
>diff -u -p -8 -r1.63 contentAreaUtils.js
>--- mozilla/browser/base/content/contentAreaUtils.js	28 Feb 2005 23:09:24 -0000	1.63
>+++ mozilla/browser/base/content/contentAreaUtils.js	13 Mar 2005 10:55:01 -0000
>@@ -690,17 +690,17 @@ function getPostData()

I wish I knew what this really meant. :)

> //XXXPch: that that be removed.
> function getStringBundle()


>         // Note - this code is identical to that in 
>-        //   browser/base/content/contentAreaUtils.js. 
>+        //   mozilla/toolkit/content/contentAreaUtils.js.

nit: drop the mozilla/ part

r=me, but please talk to justdave to get the files cvs moved instead of just
copy and land.

Comment 111

[Steffen Wilberg]

> hmm, so why hasn't this broken tbird yet?  Or do they not actually use the
> functions in contentAreaUtils.js that depend on this?
Save Page As *is* broken in Thunderbird's View Source on trunk right now. TB
uses xpfe's contentAreaUtils.js, which depends on XPCNativeWrapper.js,
introduced by bug 220215. Also see bug 248964.

Comment 112

[Steffen Wilberg]

Chase, justdave said you'll do this. Please copy these files, preserving their
history:
1) browser/base/content/contentAreaUtils.js --> toolkit/content/contentAreaUtils.js

2) browser/locales/en-US/chrome/browser/contentAreaCommands.properties -->
toolkit/locales/en-US/chrome/global/contentAreaCommands.properties

Thanks.

Comment 113

[Chase Phillips]

(In reply to comment #112)
> Chase, justdave said you'll do this. Please copy these files, preserving their
> history:
> 1) browser/base/content/contentAreaUtils.js -->
toolkit/content/contentAreaUtils.js
> 
> 2) browser/locales/en-US/chrome/browser/contentAreaCommands.properties -->
> toolkit/locales/en-US/chrome/global/contentAreaCommands.properties
> 
> Thanks.

I've been told the blame history is the important piece to keep.  I may copy the
two files listed above and then adjust the times their revisions were created to
the time the files were copied.

Comment 114

[Steffen Wilberg]

> I've been told the blame history is the important piece to keep.
Yes. That includes the change log, doesn't it?

> I may copy the two files listed above and then adjust the times their revisions 
> were created to the time the files were copied.
I'm not sure what you mean here. The time of the last change? Like 2005-03-15
18:37 for revision 1.64 of contentAreaUtils.js?

Comment 115

[Dave Miller [:justdave]]

(In reply to comment #112)
> Chase, justdave said you'll do this.

For the record, I did not tell you he was doing it.  I told you he was looking
at it.  The idea being that he needed to sign off on it before it could happen.

Comment 116

[Chase Phillips]

(In reply to comment #112)
> Chase, justdave said you'll do this. Please copy these files, preserving their
> history:
> 1) browser/base/content/contentAreaUtils.js -->
toolkit/content/contentAreaUtils.js
> 
> 2) browser/locales/en-US/chrome/browser/contentAreaCommands.properties -->
> toolkit/locales/en-US/chrome/global/contentAreaCommands.properties
> 
> Thanks.

This has been done.  Please confirm that this works as expected.  Trunk
revisions should be retained in the new location with their revision commit
times set to today.

Comment 117

[Steffen Wilberg]

Thanks Chase, looks good! You missed rev. 1.65 of contentAreaUtils.js, but I
checked that into the toolkit version before I did this:

Checking in mozilla/toolkit/components/viewsource/content/viewSource.xul;
/cvsroot/mozilla/toolkit/components/viewsource/content/viewSource.xul,v  <-- 
viewSource.xul
new revision: 1.19; previous revision: 1.18
done
Checking in mozilla/toolkit/components/viewsource/content/viewPartialSource.xul;
/cvsroot/mozilla/toolkit/components/viewsource/content/viewPartialSource.xul,v 
<--  viewPartialSource.xul
new revision: 1.16; previous revision: 1.15
done
Checking in mozilla/toolkit/components/viewsource/content/viewPartialSource.js;
/cvsroot/mozilla/toolkit/components/viewsource/content/viewPartialSource.js,v 
<--  viewPartialSource.js
new revision: 1.8; previous revision: 1.7
done
Checking in mozilla/browser/base/content/browser-scripts.inc;
/cvsroot/mozilla/browser/base/content/browser-scripts.inc,v  <-- 
browser-scripts.inc
new revision: 1.8; previous revision: 1.7
done
Checking in mozilla/browser/base/content/pageInfo.xul;
/cvsroot/mozilla/browser/base/content/pageInfo.xul,v  <--  pageInfo.xul
new revision: 1.21; previous revision: 1.20
done
Checking in mozilla/browser/base/content/web-panels.xul;
/cvsroot/mozilla/browser/base/content/web-panels.xul,v  <--  web-panels.xul
new revision: 1.15; previous revision: 1.14
done
Removing mozilla/browser/base/content/contentAreaUtils.js;
/cvsroot/mozilla/browser/base/content/contentAreaUtils.js,v  <-- 
contentAreaUtils.js
new revision: delete; previous revision: 1.65
done
Checking in mozilla/browser/components/history/content/history-panel.xul;
/cvsroot/mozilla/browser/components/history/content/history-panel.xul,v  <-- 
history-panel.xul
new revision: 1.29; previous revision: 1.28
done
Checking in mozilla/toolkit/mozapps/downloads/content/downloads.xul;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.xul,v  <-- 
downloads.xul
new revision: 1.15; previous revision: 1.14
done
Checking in mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in;
/cvsroot/mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in,v  <-- 
nsHelperAppDlg.js.in
new revision: 1.25; previous revision: 1.24
done
Checking in mozilla/toolkit/content/contentAreaUtils.js;
/cvsroot/mozilla/toolkit/content/contentAreaUtils.js,v  <--  contentAreaUtils.js
new revision: 1.66; previous revision: 1.65
done
Checking in mozilla/toolkit/content/jar.mn;
/cvsroot/mozilla/toolkit/content/jar.mn,v  <--  jar.mn
new revision: 1.12; previous revision: 1.11
done
Checking in mozilla/browser/base/jar.mn;
/cvsroot/mozilla/browser/base/jar.mn,v  <--  jar.mn
new revision: 1.85; previous revision: 1.84
done
Removing
mozilla/browser/locales/en-US/chrome/browser/contentAreaCommands.properties;
/cvsroot/mozilla/browser/locales/en-US/chrome/browser/contentAreaCommands.properties,v
 <--  contentAreaCommands.properties
new revision: delete; previous revision: 1.3
done
Checking in mozilla/browser/locales/jar.mn;
/cvsroot/mozilla/browser/locales/jar.mn,v  <--  jar.mn
new revision: 1.12; previous revision: 1.11
done
Checking in mozilla/toolkit/locales/jar.mn;
/cvsroot/mozilla/toolkit/locales/jar.mn,v  <--  jar.mn
new revision: 1.18; previous revision: 1.17
done

Marking fixed finally.
Save As in Thunderbird's View Source is broken right now, but that's not due to
these changes.

Comment 118

[Worcester12345]

(In reply to comment #117)

> Save As in Thunderbird's View Source is broken right now, but that's not due to
> these changes.

Bug #?