Closed Bug 652404 Opened 9 years ago Closed 9 years ago

Internal Error Bugzilla 4.0 Can't call method "_changes_everconfirmed" on unblessed reference at /data/www/bugzilla.mozilla.org/Bugzilla/Bug.pm line 3868

Categories

(bugzilla.mozilla.org :: General, defect, P1)

Tracking

()

VERIFIED FIXED

People

(Reporter: raul.malea, Assigned: glob)

References

()

Details

(Keywords: regression)

Attachments

(2 files)

I try to report new bug for Firefox. 

Bugzilla has suffered an internal error. Please save this page and send it to bugzilla-admin@mozilla.org with details of what you were doing at the time this message appeared.

URL: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox
undef error - Can't call method "_changes_everconfirmed" on unblessed reference at /data/www/bugzilla.mozilla.org/Bugzilla/Bug.pm line 3868.

Traceback:


Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0 ID:20110318052756
Flags: blocking4.0.1?
Keywords: regression
OS: Windows 7 → All
Hardware: x86 → All
Whiteboard: [bugzilla 4.0]
I don't see the error you are reporting. Anyway, if the problem is real, it's very likely due to a customization in bmo code.
Assignee: create-and-change → nobody
Status: NEW → RESOLVED
Closed: 9 years ago
Component: Creating/Changing Bugs → Bugzilla: Other b.m.o Issues
Flags: blocking4.0.1?
Product: Bugzilla → mozilla.org
QA Contact: default-qa → other-bmo-issues
Resolution: --- → WORKSFORME
Whiteboard: [bugzilla 4.0]
Version: 4.0 → other
(In reply to comment #1)
> Anyway, if the problem is real, it's
> very likely due to a customization in bmo code.

This was reported in mozilla.org::Bugzilla not Bugzilla::X ?
@Ed, Yes is bug for mozilla.org, component Bugzilla.

Bug reopened because is real. For me, in more situation error was appear:

https://bugzilla.mozilla.org/enter_bug.cgi?product=Add-on%20SDK

https://bugzilla.mozilla.org/enter_bug.cgi?product=Mozilla%20Localizations

https://bugzilla.mozilla.org/enter_bug.cgi?product=Core

etc. etc.

But in other links forms forms bug reporting appear, for example: https://bugzilla.mozilla.org/enter_bug.cgi?product=Mozilla%20Communities

I try also in new profile in Fx4 and new profile in Nightly.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Attached image Internal error bugzilla 4 β€”
This happens when some code tries to call check_can_change_field during bug creation time, when it cannot be called. (It's an instance method, not a class method.)
Confirming that this error message is occurring whenever I try to file a bug under Firefox.
weird; i can't reproduce on my local environment.  investigating...
Priority: -- → P1
i can't reproduce on bmo as myself either, so it's probably permissions based.
Status: REOPENED → NEW
note: the error happens when the enter_bug page is loaded, not after hitting submit.
undef error - Can't call method "_changes_everconfirmed" on unblessed reference at Bugzilla/Bug.pm line 3868.
 at Bugzilla/Bug.pm line 3868
	Bugzilla::Bug::check_can_change_field('HASH(0x38f5324)', 'cf_blocking_fennec', 0, '---') called at ./extensions/BMO/Extension.pm line 129
	Bugzilla::Extension::BMO::__ANON__('cf_blocking_fennec', 0, '---') called at template\en\default\bug\field.html.tmpl line 134
	eval {...} called at template\en\default\bug\field.html.tmpl line 176
	eval {...} called at template\en\default\bug\field.html.tmpl line 18
	Template::Provider::__ANON__('Bugzilla::Template::Context=HASH(0x4280ecc)') called at C:/dev/bugzilla/perl/perl/site/lib/Template/Document.pm line 151
	eval {...} called at C:/dev/bugzilla/perl/perl/site/lib/Template/Document.pm line 149
	Template::Document::process('Template::Document=HASH(0x7761d84)', 'Bugzilla::Template::Context=HASH(0x4280ecc)') called at C:/dev/bugzilla/perl/perl/site/lib/Template/Context.pm line 351
	eval {...} called at C:/dev/bugzilla/perl/perl/site/lib/Template/Context.pm line 321
	Template::Context::process('Bugzilla::Template::Context=HASH(0x4280ecc)', 'bug/field.html.tmpl', 'HASH(0x94db324)', 'localize me!') called at Bugzilla/Template/Context.pm line 45
	Bugzilla::Template::Context::process('Bugzilla::Template::Context=HASH(0x4280ecc)', 'bug/field.html.tmpl', 'HASH(0x94db324)', 'localize me!') called at C:/dev/bugzilla/perl/perl/site/lib/Template/Context.pm line 409
	Template::Context::include('Bugzilla::Template::Context=HASH(0x4280ecc)', 'bug/field.html.tmpl', 'HASH(0x94db324)') called at template\en\default\bug\create\create.html.tmpl line 507
	eval {...} called at template\en\default\bug\create\create.html.tmpl line 511
	eval {...} called at template\en\default\bug\create\create.html.tmpl line 18
	Template::Provider::__ANON__('Bugzilla::Template::Context=HASH(0x4280ecc)') called at C:/dev/bugzilla/perl/perl/site/lib/Template/Document.pm line 151
	eval {...} called at C:/dev/bugzilla/perl/perl/site/lib/Template/Document.pm line 149
	Template::Document::process('Template::Document=HASH(0x4837884)', 'Bugzilla::Template::Context=HASH(0x4280ecc)') called at C:/dev/bugzilla/perl/perl/site/lib/Template/Context.pm line 351
	eval {...} called at C:/dev/bugzilla/perl/perl/site/lib/Template/Context.pm line 321
	Template::Context::process('Bugzilla::Template::Context=HASH(0x4280ecc)', 'Template::Document=HASH(0x4837884)') called at Bugzilla/Template/Context.pm line 45
	Bugzilla::Template::Context::process('Bugzilla::Template::Context=HASH(0x4280ecc)', 'Template::Document=HASH(0x4837884)') called at C:/dev/bugzilla/perl/perl/site/lib/Template/Service.pm line 94
	eval {...} called at C:/dev/bugzilla/perl/perl/site/lib/Template/Service.pm line 91
	Template::Service::process('Template::Service=HASH(0x418825c)', 'bug/create/create.html.tmpl', 'HASH(0x417b934)') called at C:/dev/bugzilla/perl/perl/site/lib/Template.pm line 66
	Template::process('Bugzilla::Template=HASH(0x417bbe4)', 'bug/create/create.html.tmpl', 'HASH(0x417b934)') called at Bugzilla/Template.pm line 558
	Bugzilla::Template::process('Bugzilla::Template=HASH(0x417bbe4)', 'bug/create/create.html.tmpl', 'HASH(0x417b934)') called at C:/dev/bugzilla/htdocs/bmo_4.0/enter_bug.cgi line 605


so it looks like a problem with the customisation to template/en/default/bug/field.html.tmpl for custom field visibility.
Assignee: nobody → glob
i have temporarily removed the following custom fields from the create-bug form until this has been resolved:

cf_tracking_firefox5
cf_status_firefox5
cf_blocking_fennec 
cf_blocking_20
cf_status_20
cf_blocking_192
cf_status_192
cf_blocking_191
cf_status_191
cf_blocking_thunderbird33
cf_status_thunderbird33 
cf_blocking_thunderbird31
cf_status_thunderbird31 
cf_blocking_seamonkey21
cf_status_seamonkey21
Severity: critical → major
After those changes that you made, I can now see the enter bug form for Firefox.
We solved this in bmo 3.6 by passing a Bugzilla::FakeBug object into the template which had the methods from Bug.pm we were using stubbed in.  I'm guessing that object didn't make it into our port to 4.0 or it's missing this method.
Attached patch patch v1 β€” β€” Splinter Review
this patch should address the issue.  it brings back the FakeBug object, which is injected into the template from the extension.
Attachment #528087 - Flags: review?
Attachment #528087 - Flags: feedback?
Sigh. I had a patch ready to go for this that was waiting on review and slipped through the cracks. bug 587306 had a patch for 3.6 and 4.0 and the 3.6 one got committed but not the 4.0. glob's patch does essentially the same thing so I will review and commit today. We can then turn back on the custom fields.

dkl
Status: NEW → ASSIGNED
Sorry, I missed doing that review :-(

Gerv
Committing to: bzr+ssh://dlawrence%40mozilla.com@bzr.mozilla.org/bmo/4.0
modified template/en/default/bug/field.html.tmpl
modified extensions/BMO/Extension.pm
added extensions/BMO/lib/FakeBug.pm
Committed revision 7613.
(In reply to comment #11)
> i have temporarily removed the following custom fields from the create-bug form
> until this has been resolved:
> 
> cf_tracking_firefox5
> cf_status_firefox5
> cf_blocking_fennec 
> cf_blocking_20
> cf_status_20
> cf_blocking_192
> cf_status_192
> cf_blocking_191
> cf_status_191
> cf_blocking_thunderbird33
> cf_status_thunderbird33 
> cf_blocking_thunderbird31
> cf_status_thunderbird31 
> cf_blocking_seamonkey21
> cf_status_seamonkey21

That patch is now live on BMO and I have re-enabled to above fields for the enter_bug.cgi form. Please confirm this bug is fixed by changing to VERIFIED.

dkl
Status: ASSIGNED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
(In reply to comment #18)
> (In reply to comment #11)
> > i have temporarily removed the following custom fields from the create-bug form
> > until this has been resolved:
> > 
> > cf_tracking_firefox5
> > cf_status_firefox5
> > cf_blocking_fennec 
> > cf_blocking_20
> > cf_status_20
> > cf_blocking_192
> > cf_status_192
> > cf_blocking_191
> > cf_status_191
> > cf_blocking_thunderbird33
> > cf_status_thunderbird33 
> > cf_blocking_thunderbird31
> > cf_status_thunderbird31 
> > cf_blocking_seamonkey21
> > cf_status_seamonkey21
> 
> That patch is now live on BMO and I have re-enabled to above fields for the
> enter_bug.cgi form. Please confirm this bug is fixed by changing to VERIFIED.
> 
> dkl

Confirm: fixed. Good job! Thanks!
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
Attachment #528087 - Flags: review?
Attachment #528087 - Flags: feedback?
You need to log in before you can comment on or make changes to this bug.