Closed Bug 222157 Opened 21 years ago Closed 19 years ago

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

Categories

(Toolkit :: View Source, defect, P4)

Product:
Toolkit
Component:
View Source
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7.5

People

(Reporter: ehume, Assigned: steffen.wilberg)

References

Details

(Keywords: fixed-aviary1.0, regression)

Attachments

(1 file, 5 obsolete files)

the real patch: move contentAreaUtils.js to toolkit
24.86 KB, patch
mconnor
: review+
Details | Diff | Splinter Review 
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.
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.
Keywords: regression
Summary: No 'Find' function in View Source → View Source: Save as, Print, Find don't work
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.
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.
-> me
I'll fix sometimes soon, but I want to fix it the proper way ie by fixing the
bogus dependencies.
Assignee: blake → p_ch
I just hooked up page setup and print functionalities.
However I don't have a printer handy.
So your feedback will be really appreciated!
Printer?
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).
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.
Printing now works, but the find and save functions still don't.
*** Bug 223881 has been marked as a duplicate of this bug. ***
Adjusting summary.
QA Contact: bugzilla
Summary: View Source: Save as, Print, Find don't work → View Source: Save as and Find don't work
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.
*** Bug 205815 has been marked as a duplicate of this bug. ***
*** Bug 184741 has been marked as a duplicate of this bug. ***
.
URL: any
Severity: normal → major
Summary: View Source: Save as and Find don't work → View Source: Save as, Find and Find Again don't work
Flags: blocking0.8?
I see this bug on Linux too, with 20031101.  --> All/All.
OS: Windows XP → All
Hardware: PC → All
If you don't want this pierre reassign to me.
Priority: -- → P3
Target Milestone: --- → Firebird0.8
Ben: I've just cut the last comm.jar dependencies in the toolkit.
Now, it's time for me to work on that.
*** Bug 225352 has been marked as a duplicate of this bug. ***
*** Bug 225336 has been marked as a duplicate of this bug. ***
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

 
This is not about View Selection Source not showing the right text.
*** Bug 226269 has been marked as a duplicate of this bug. ***
Thanks for the patience, everybody!
find in page is fixed. 
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.

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.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
it applies to SVG aswell
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.:-(
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".
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: View Source: Save as, Find and Find Again don't work → View Source: Save Page As doesn't work
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 :-(
Indeed. Reverting summary...
Summary: View Source: Save Page As doesn't work → View Source: Save as, Find and Find Again don't work
Whiteboard: find commands fixed
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.
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?
Same problem here, with Gecko/20031122 Firebird/0.7+, windows xp. Find doest 
work. nothing gets selected. Using the installer build.
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.

Also, please verify with an unzipped build, not just an installer, to make sure
it is not an installer problem.
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
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.
Installing to a new dir?  new profile?  Installer bugs should be filed seperately.
> 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? 
Yes, please.  And assign it to the Installer component.
bug 226674 was filed for the issues mentioned in comment 38.
So the only thing remaining is the "save as" in the viewsource. Everything else
works here in the zip version.
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.
Severity: major → minor
Flags: blocking0.8? → blocking0.8-
-> 0.9
Target Milestone: Firebird0.8 → Firebird0.9
I re added the mozilla/browser dependency to fix the 'save as' functionality,
but only on the branch.
Blocks: majorbugs
(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?
because it introduces an undesirable dependency, and its better to wait on a
real fix instead of doing a band-aid.
Attached patch Fixes Save As functionality (obsolete) — — Splinter Review 
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 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.
Attachment #144931 - Attachment is obsolete: true
Aye, sorry for the spam, should have checked first.
Flags: blocking0.9?
not going to block 0.9 on this request to add the save as feature to view source.
Flags: blocking0.9? → blocking0.9-
Summary: View Source: Save as, Find and Find Again don't work → View Source: Save as dosn't work (Find and Find Again have been fixed)
Summary: View Source: Save as dosn't work (Find and Find Again have been fixed) → View Source: Save as doesn't work (Find, Find Again have been fixed)
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+
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+
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+
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+
(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?
Flags: blocking1.0?
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.
one or the other will happen by 1.0, not necessarily by 0.9.
Flags: blocking1.0? → blocking1.0-
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 ... :(
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.
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?
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.
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?
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.
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.
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');
Assignee: p_ch → steffen.wilberg
Status: REOPENED → ASSIGNED
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.
Attached patch fix thunderbird as well (obsolete) — — Splinter Review 
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.
Attachment #147936 - Attachment is obsolete: true
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.
Attachment #149283 - Flags: review?(mconnor)
Rerequesting blocking1.0 since there's a patch now.
Flags: blocking1.0- → blocking1.0?
Comment on attachment 149283 [details] [diff] [review]
fix thunderbird as well

aren't we missing the bit for packing contentAreaUtils.properties into global?
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>
*** Bug 246013 has been marked as a duplicate of this bug. ***
-> View Source.
Component: General → View Source
QA Contact: bugzilla → firefox.view-source
Flags: blocking1.0? → blocking1.0+
-> 1.0beta
Target Milestone: Firefox0.9 → Firefox1.0beta
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.
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.
re comment 77 - the issue with Mozilla is bug 248964
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 on attachment 149283 [details] [diff] [review]
fix thunderbird as well

I need to update this patch.
Attachment #149283 - Attachment is obsolete: true
Attachment #149283 - Flags: review?(mconnor)
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?
Flags: blocking0.9-
Flags: blocking0.8-
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?
I think it's too late now for my previous patch.
But I'll make a new band-aid (reintroduce the browser dependency) tomorrow.
Target Milestone: Firefox1.0beta → Firefox1.0
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 on attachment 161005 [details] [diff] [review]
band-aid for the branch (Firefox and Thunderbird)

Works fine on both Firefox and Thunderbird.
Attachment #161005 - Flags: review?(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
Attachment #161005 - Flags: review?(mconnor) → review?(vladimir)
p4 priority - not a blocker. if a fully reviewed patch materializes, please
nominate for aviary approval.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
For Aviary, I suggest removing/hiding the the grayed out "save page as" menuitem.
Attachment #161005 - Attachment description: band-aid for Firefox and Thunderbird → band-aid for the branch (Firefox and Thunderbird)
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.
Same as before, but applies again.
Attachment #161005 - Attachment is obsolete: true
Attachment #161005 - Flags: review?(vladimir)
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.
Attachment #163260 - Flags: review?(bryner)
Attachment #163260 - Flags: approval-aviary?
Attachment #163260 - Flags: review?(bryner) → review+
Comment on attachment 163260 [details] [diff] [review]
band-aid, unbitrotted [checked in: comment 94]

a=asa.
Attachment #163260 - Flags: approval-aviary? → approval-aviary+
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.
Keywords: fixed-aviary1.0
Whiteboard: find commands fixed → trunk still needs a proper fix
Attachment #163260 - Attachment description: band-aid, unbitrotted → band-aid, unbitrotted [checked in: comment 94]
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.
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.
vrfy'd fixed with 2004102609-0.11 (aviary1.0) bits on linux fc2. able to save
from source again.
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
> 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
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.
#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.
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/
This all seems to work for me now in a 20041224 trunk build on Windows 2000.
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).
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041228
Firefox/1.0+

WFM


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.
(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?
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.
Attachment #163260 - Attachment is obsolete: true
Attachment #177272 - Flags: review?(mconnor)
Requesting blocking since there is now a patch.
Flags: blocking-aviary1.1?
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.
Attachment #177272 - Flags: review?(mconnor) → review+
> 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.
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.
(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.
> 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?
(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.

(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.
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.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 19 years ago
Flags: blocking-aviary1.1?
Resolution: --- → FIXED
Whiteboard: trunk still needs a proper fix
No longer blocks: majorbugs
(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 #?
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: