If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

When cloning a bug custom fields are copied even if the reporter doesn't have permission to set them, doesn't allow for editing.

NEW
Unassigned

Status

()

bugzilla.mozilla.org
General
P3
normal
7 years ago
a year ago

People

(Reporter: John J. Barton, Unassigned)

Tracking

Details

(Whiteboard: Summary in comment 4)

(Reporter)

Description

7 years ago
+++ This bug was initially created as a clone of Bug #620218 +++

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101217 Firefox/4.0b9pre ID:20101217030324

Seen this today while reading some posts on the Google Chrome Releases blog. Loading the page given in the URL field uses about 1GB of memory (that's the remaining physical memory on my box) and hang the browser for about 15 seconds.

Looks like it is related to some Javascript code, which get run on this site. Disabling JS solves this issue.
Not sure what this bug is about but I think you have it created accidentally.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
No longer depends on: 620218, 610793, 619749
Resolution: --- → DUPLICATE
Duplicate of bug: 620218
(Reporter)

Updated

7 years ago
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Comment 2

7 years ago
According to Boris on Bug 620218 
I set Wanted flags when I created that bug. All I did was "clone", bugzilla set the wanted flags. (note to self, don't use clone again ;-)
Severity: critical → normal
Status: REOPENED → NEW
Summary: Loading a web page hangs browser (>1GB of additional memory usage) when javascript.options.strict enabled and any console service is attached → bugzilla sets 'wanted' flags when you clone a bug.
(Reporter)

Updated

7 years ago
Keywords: hang
This is a dupe, though I can't find the dupe right now.
Assignee: mozillamarcia.knous → nobody
Component: Bugzilla: Keywords & Components → Bugzilla: Other b.m.o Issues
QA Contact: timeless → other-bmo-issues
Whiteboard: DUPEME
I've been searching, trying to find a bug filed for this but can't find it. I don't think this is a bmo bug, it's a Bugzilla bug, so moving.

The issue is that all custom fields are pre-populated with the data from the cloned bug (which is technically correct) without regard for the reporter's credentials and permissions. They can't be edited either.
Assignee: nobody → create-and-change
Component: Bugzilla: Other b.m.o Issues → Creating/Changing Bugs
Product: mozilla.org → Bugzilla
QA Contact: other-bmo-issues → default-qa
Summary: bugzilla sets 'wanted' flags when you clone a bug. → When cloning a bug custom fields are copied even if the reporter doesn't have permission to set them, doesn't allow for editing.
Whiteboard: DUPEME → Summary in comment 4
Version: other → unspecified

Comment 5

7 years ago
(In reply to comment #4)
> don't think this is a bmo bug, it's a Bugzilla bug, so moving.

No, this is not a Bugzilla bug. Everyone is free to edit custom fields on bug creation, independently of his privs. The pseudo-flags discussed in this bug do not exist upstream. It's a bmo customization.
Assignee: create-and-change → nobody
Component: Creating/Changing Bugs → Bugzilla: Other b.m.o Issues
Product: Bugzilla → mozilla.org
QA Contact: default-qa → other-bmo-issues
Version: unspecified → other
Can you please re-verify this is still a problem? A fix was pushed out recently that fixed custom field values not displaying properly for enter_bug.cgi which could have also caused this problem.

Dave
Still an issue, I just cloned bug 637542 (didn't actually submit) and the final+ blocking was the value in the blocking2.0 field.

If you want me to actually submit a test bug, I can do that too (then again, so can you).
(Assignee)

Updated

6 years ago
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
Still an issue with current code. Will need to investigate further.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.