Closed Bug 406222 Opened 17 years ago Closed 16 years ago

The location bar in javascript popups can be modified if user right clicks and selects cut

Categories

(Firefox :: Address Bar, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 3 beta4

People

(Reporter: ben.r.xiao, Assigned: dao)

References

Details

(Keywords: regression)

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007113005 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b2pre) Gecko/2007113005 Minefield/3.0b2pre

Recently, the devs decided to display a non-editable location bar in all pop ups to prevent fraudulent websites. However, a user can right click in the location bar, highlight the URL, and select cut to modify the URL. This should be prevented for both consistency and security reasons

Reproducible: Always

Steps to Reproduce:
1.Go to a website that pops up a javascript window
2.Right click on location bar, select some text
3.Select cut to delete it
Actual Results:  
The selected text is deleted

Expected Results:  
Either cut should be disabled, or the cut function does nothing.
Seems likely to be because of the way the urlbar binding's isCommandEnabled in http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/browser/base/content/urlbarBindings.xml&rev=1.45&mark=205-215#176 is indifferent to whether or not the urlbar is readonly.
Status: UNCONFIRMED → NEW
Component: Toolbars → Location Bar and Autocomplete
Ever confirmed: true
QA Contact: toolbars → location.bar
Blocks: 366797
Keywords: regression
OS: Windows Vista → All
Hardware: PC → All
Version: unspecified → Trunk
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #290928 - Flags: review?(gavin.sharp)
Is having doCommand call isCommandEnabled required to fix this bug? I'm not sure it's correct, and the nonexistent interface docs aren't helping me figure that out.
The extra check is needed for Ctrl+X. Apparently not all doCommand callers do that.
(In reply to comment #4)
> The extra check is needed for Ctrl+X. Apparently not all doCommand callers do
> that.

Maybe that's the bug we should fix, then...
Interestingly pressing Ctrl+X on a readonly input copies the text... I'm not 100% sure that this is an XBL bug but as far as I know all the other places check that the command is enabled first.
Attached patch patch v2 (obsolete) — Splinter Review
this makes Ctrl+X copy the selection
Attachment #290928 - Attachment is obsolete: true
Attachment #291079 - Flags: review?(gavin.sharp)
Attachment #290928 - Flags: review?(gavin.sharp)
On a related note, why is Undo enabled in the context menu?
Attached patch patch v3Splinter Review
what the second patch did, plus updating the pageproxystate
Attachment #291079 - Attachment is obsolete: true
Attachment #300563 - Flags: review?(gavin.sharp)
Attachment #291079 - Flags: review?(gavin.sharp)
Attachment #300563 - Flags: review?(gavin.sharp) → review+
Attachment #300563 - Flags: approval1.9?
Attachment #300563 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
Checking in browser/base/content/urlbarBindings.xml;
/cvsroot/mozilla/browser/base/content/urlbarBindings.xml,v  <--  urlbarBindings.xml
new revision: 1.55; previous revision: 1.54
done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 beta4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: