Closed Bug 471935 Opened 11 years ago Closed 11 years ago

Copying Text from about:privatebrowsing page and then pasting yields different text

Categories

(Firefox :: Private Browsing, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 3.6a1

People

(Reporter: marcia, Assigned: ehsan)

Details

(Keywords: verified1.9.1)

Attachments

(2 files)

Seen while testing  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090102 Shiretoko/3.1b3pre

STR
1. Visit about:privatebrowsing page in regular browsing mode.
2. Copy text on that page and then paste into a text document.

Expected: It would copy the text as rendered on the page.

Actual: It copies the text that you would see when you are in in Private Browsing mode as seen below:

Would you like to start Private Browsing?

Shiretoko won't remember any history for this session.

Shiretoko is not currently in Private Browsing mode.

In a Private Browsing session, Shiretoko won't keep any browser history, search history, download history, web form history, cookies, or temporary internet files.  However, files you download and bookmarks you make will be kept.
  
You may want to start by also clearing your recent history.

        


        
        

          
        


        
        

          

To stop Private Browsing, select Tools > Stop Private Browsing, or close Shiretoko.

To start Private Browsing, you can also select Tools > Start Private Browsing.
This is because of bug 39098, we use CSS to hide the alternate version of the about:privatebrowsing page. We could actually remove the other elements, or dynamically document.write instead or something, I guess.
Removing the other elements is what netError.xhtml does, to work around this problem, it's probably what we should do here if we want to support copy/paste of this text for some reason. Except of course that what we should really do is just fix bug 39098  :)
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
Attached patch Patch (v1)Splinter Review
Attachment #356154 - Flags: review?(gavin.sharp)
OS: Mac OS X → All
Hardware: x86 → All
Attachment #356154 - Flags: review?(gavin.sharp) → review+
Attached patch Checked inSplinter Review
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/029630824401
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-litmus?
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.2a1
Attachment #356669 - Attachment description: For check-in → Checked in
Attachment #356669 - Flags: approval1.9.1?
Verified FIXED on trunk using  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090215 Minefield/3.2a1pre.
Status: RESOLVED → VERIFIED
Comment on attachment 356669 [details] [diff] [review]
Checked in

a191=beltzner
Attachment #356669 - Flags: approval1.9.1? → approval1.9.1+
Verified fixed on the 1.9.1 branch using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090330 Shiretoko/3.5b4pre.
I am not totally convinced we need a Litmus test case for this since it is relatively minor bug.  Thoughts?
(In reply to comment #11)
> I am not totally convinced we need a Litmus test case for this since it is
> relatively minor bug.  Thoughts?

Hmm, yes it is, but what's the downside with having a Litmus test case here?  I'd imagine the fact that testers would have to take the time to run one more test all the time...  I'm not really sure what the criteria for Litmus case eligibility is, feel free to minus this since I think the chances of it regressing are pretty low as well.
Going to minus this one. It would end up in the FFT, and I think would probably not be run that often.
Flags: in-litmus? → in-litmus-
You need to log in before you can comment on or make changes to this bug.