Firefox developer edition doesn't display AJAX request parameters in network monitor

VERIFIED FIXED in Firefox 45

Status

defect
P3
normal
VERIFIED FIXED
3 years ago
10 months ago

People

(Reporter: cvetan.simsic, Assigned: ntim)

Tracking

(Depends on 1 bug, {regression})

45 Branch
Firefox 46
Dependency tree / graph

Firefox Tracking Flags

(firefox44 unaffected, firefox45+ verified, firefox46 verified)

Details

(Whiteboard: [polish-backlog], URL)

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

3 years ago
Posted image network-monitor.png
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151210085006

Steps to reproduce:

When i send AJAX request, the parameters are not listed in network monitor. I use latest Developer edition in Ubuntu MATE 14.04.
(Reporter)

Updated

3 years ago
Component: Untriaged → Developer Tools: Netmonitor
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
I can confirm this is also happening in Nightly, and has been for weeks. This makes debugging asynchronous requests next to impossible. This is fairly critical functionality. I've had to fire up Chrome to get my work done, unfortunately.
(Assignee)

Comment 3

3 years ago
I can reproduce using the testcase from comment 2 (thanks Dane !).

STR:
- Open the testcase from comment 2
- Check the network monitor
- Click one of the network requests entry
- Click Params

AR:
See attachment 8701467 [details].

ER:
Params should be visible.
Has STR: --- → yes
OS: Linux → All
Hardware: x86_64 → All
(Assignee)

Updated

3 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

3 years ago
Whiteboard: [polish-backlog]
From IRC:

          ntim │ danemacmillan: Yes, I can reproduce the bug
 danemacmillan │ Ok great.
 danemacmillan │ I added that fiddle to the ticket
 danemacmillan │ Thanks for confirming the bug on bugzilla--hopefully that ticket gets some love soonish. Can't stand using Chrome devtools :(
          ntim │ danemacmillan: what's strange is that requests that happened *before* the netmonitor was opened show "No parameters for this request"
          ntim │ while those which happened *after* show the empty variables view as shown in the screenshot
          ntim │  danemacmillan: do you know if this is only a recent issue ?
 danemacmillan │ While the ticket was just created, I have been experiencing it for at least an entire version's lifecycle, if not a bit more. It wasn't until
               │ recently, though, that I seriously needed access to it, so tolerance for it dropped. Using Nightly for so many years, I don't raise alarm bells
               │ right away, as I just figure someone regressed something in the latest build and will get caught next time
 danemacmillan │ around. This one has been lingering a while longer than usual, though.
 danemacmillan │ I can't be more precise than that. I just know I've been complaining about it with some colleagues of late.
          ntim │ danemacmillan: so it's a regression, not a bug that was initially in the implementation
          ntim │ right ?
 danemacmillan │ Oh no--it has absolutely worked in the past.
 danemacmillan │ So it's definitely a regression
          ntim │ danemacmillan: Can you try to use this tool for getting a small regression range ? http://mozilla.github.io/mozregression/
          ntim │ (I have slow wifi, so it would take me hours for me to run this tool)
 danemacmillan │ Okay sure, I'll try this when I get home
          ntim │ Thanks
 danemacmillan │ I just opened up stable Firefox (version 42) and it works: https://i.imgur.com/eIGcClp.png
 danemacmillan │ I'll update to 44 and see if it still works
 danemacmillan │ It also works in the latest update to stable Firefox (version 44): https://i.imgur.com/KGGhJ6E.png
 danemacmillan │ So if it happens in Developer (v45) like the OP of the ticket, and I'm seeing it in Nightly (v46), it was definitely introduced in v45
 danemacmillan │ As it is still happening in Nightly, a full six weeks ahead of 45
(Assignee)

Comment 5

3 years ago
[Tracking Requested - why for this release]: Regression in developer tools
(Assignee)

Comment 6

3 years ago
Last good revision: d2906d28d9ed99ee4b2b93cc22bef718f3e81de4
First bad revision: 4ea8997d2ed880ae1a7346e5869c4fc644d186f7

Pushlog: https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=d2906d28d9ed99ee4b2b93cc22bef718f3e81de4&tochange=4ea8997d2ed880ae1a7346e5869c4fc644d186f7

Regressed by: Gijs Kruitbosch — Bug 1122102 - post json params shouldn't be displayed as text in params>request payload, r=vporof

Gijs is not accepting any needinfo requests, so needinfo'ing Victor instead :)
Depends on: 1122102
Flags: needinfo?(vporof)
(Assignee)

Comment 7

3 years ago
Posted patch Patch (obsolete) — Splinter Review
I'm not sure what use case the `onlyEnumVisible: true,` argument fixes here, really.
Assignee: nobody → ntim.bugs
Status: NEW → ASSIGNED
Flags: needinfo?(vporof)
Attachment #8701777 - Flags: review?(vporof)
(Assignee)

Comment 8

3 years ago
Posted patch Patch v1.1 (obsolete) — Splinter Review
Attachment #8701777 - Attachment is obsolete: true
Attachment #8701777 - Flags: review?(vporof)
Attachment #8701778 - Flags: review?(vporof)
(Assignee)

Comment 9

3 years ago
(In reply to Tim Nguyen [:ntim] from comment #7)
> Created attachment 8701777 [details] [diff] [review]
> Patch
> 
> I'm not sure what use case the `onlyEnumVisible: true,` argument fixes here,
> really.

Or maybe we want to have onlyEnumVisible for JSON only, I don't know.
Comment on attachment 8701778 [details] [diff] [review]
Patch v1.1

Review of attachment 8701778 [details] [diff] [review]:
-----------------------------------------------------------------

Probably copy pasta leftover. It makes sense for the json because you don't want __protos__ there, but here it's rather irrelevant.
Attachment #8701778 - Flags: review?(vporof) → review+
(Assignee)

Updated

3 years ago
Keywords: checkin-needed
(Assignee)

Comment 11

3 years ago
Posted patch Patch v2Splinter Review
Attachment #8701778 - Attachment is obsolete: true
Attachment #8701811 - Flags: review?(vporof)
(Assignee)

Updated

3 years ago
Keywords: checkin-needed
Attachment #8701811 - Flags: review?(vporof) → review+
(Assignee)

Updated

3 years ago
Keywords: checkin-needed
Victor, Tim - thanks for fixing this so quickly once we realized :)

I think we need to follow up with two things:

1. we should uplift into Dev Edition 45 ( ntim set the flags! )
2. we should have some sort of test so we don't regress in the future?
(Reporter)

Comment 14

3 years ago
Has the patch been applied to dev edition, or still not?

Because it is still the same.
(Assignee)

Comment 15

3 years ago
(In reply to cvetan.simsic from comment #14)
> Has the patch been applied to dev edition, or still not?
> 
> Because it is still the same.

It's not even in Nightly yet.

Comment 17

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/10ddceabece0
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 46
(Assignee)

Comment 18

3 years ago
Comment on attachment 8701811 [details] [diff] [review]
Patch v2

Approval Request Comment
[Feature/regressing bug #]: bug 1122102
[User impact if declined]: Broken network monitor (params not showing up)
[Describe test coverage new/current, TreeHerder]: on m-c, tested locally
[Risks and why]: Low, 3 line change
[String/UUID change made/needed]:
Attachment #8701811 - Flags: approval-mozilla-aurora?
Thanks--this is working in Nightly!
(Reporter)

Comment 20

3 years ago
Still not in dev edition though.
(Assignee)

Comment 21

3 years ago
(In reply to cvetan.simsic from comment #20)
> Still not in dev edition though.
Should be there in a week or so. Depends on when the approval request in comment 18 gets accepted.
Recent regression, tracking.
Attachment #8701811 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Updated

3 years ago
Depends on: 1235562
(Reporter)

Updated

3 years ago
Summary: Firefox developer edition dosn't display AJAX request parameters in network monitor → Firefox developer edition doesn't display AJAX request parameters in network monitor

Updated

3 years ago
Duplicate of this bug: 1235611
(Reporter)

Comment 25

3 years ago
I've just updated dev edition, the parameters still don't show up.
Yes, the patch landed 6 minutes ago. It should be in tomorrow aurora build (or the day after).
(Reporter)

Comment 27

3 years ago
It landed in dev edition. :)

Thanks guys.

Updated

3 years ago
QA Whiteboard: [good first verify]
Reproduced this bug with Firefox Developer Edition 45.0a2 (2015-12-23) (Build ID: 20151223004004) 
on Linux, 64 Bit with the instructions from comment 3.

This Bug is now verified as fixed on Latest Firefox Nightly 46.0a1 (2016-01-14) (Build ID: 20160114060719)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 and also

verified as fixed on Latest Firefox Developer Edition 45.0a2 (2016-01-14) (Build ID: 20160114004007)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
QA Whiteboard: [good first verify] → [good first verify][bugday-20160113]
I have reproduced this bug with Firefox Developer edition 45.0a2 (Build ID: 20151223004004) on 
windows 8.1, 64-bit with the instructions from comment 3.

Verified as fixed with Firefox Release 45.0 (Build ID: 20160303134406)
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0

Verified as fixed with Firefox beta 46.0a2 (Build ID: 20160316065941)
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0

As this bug is also verified on Linux(Comment 28),I am marking this as verified!
Status: RESOLVED → VERIFIED
QA Whiteboard: [good first verify][bugday-20160113] → [good first verify][bugday-20160113][testday-20160318]
I have observed similar to this bug on Firefox Developer edition 51.0a2 (2016-11-05) (64-bit) on Ubuntu 14.04 LTS. Ajax requests from a "https" page to "http" page are failing even after allowing the mixed content in about:config, and these failed requests are not being shown up in the network monitor.

Comment 31

2 years ago
Windows 7 x64

The same problem...

v51.0.1: shows JSON expanded line only... but show details after click UNDER JSON line.
v53.0a2: does not show anything at all... so parameters tab simply does not work.

How to switch it to NOT FIXED?
Flags: needinfo?(ntim.bugs)
(Assignee)

Comment 32

2 years ago
Posted image params-panel.png
(In reply to Maxim from comment #31)
> Windows 7 x64
> 
> The same problem...
> 
> v51.0.1: shows JSON expanded line only... but show details after click UNDER
> JSON line.
> v53.0a2: does not show anything at all... so parameters tab simply does not
> work.

I can't reproduce using the steps from comment 3. I'm not noticing any difference in any of the panels (except for the styling). I've attached a screenshot.

Do you have a specific webpage where this doesn't work? Can you attach a screenshot ?
Flags: needinfo?(ntim.bugs) → needinfo?(leyyyyy)

Comment 33

2 years ago
Developer tools used for current bugzilla page (in ff v51):
http://oi67.tinypic.com/1674ftg.jpg

Finally I am able to show parameters in tricky way:
http://oi64.tinypic.com/2s6uges.jpg

In developer edition "JSON" word is absent and whole right panel is blank.
Flags: needinfo?(leyyyyy)
(Assignee)

Comment 34

2 years ago
Honza, Ricky, Jarda, might be a regression from the netmonitor html changes ?
Flags: needinfo?(rchien)
Flags: needinfo?(odvarko)
Flags: needinfo?(jsnajdr)
Maxim, could you reproduce this issue on latest Nightly?

The Params Panel UI looks like the old XUL implementation in comment 33. Do you come across the same problem in Nightly?
Flags: needinfo?(rchien)
Flags: needinfo?(odvarko)
Flags: needinfo?(leyyyyy)
Flags: needinfo?(jsnajdr)
(Assignee)

Comment 36

2 years ago
(In reply to Ricky Chien [:rickychien] from comment #35)
> Maxim, could you reproduce this issue on latest Nightly?
> 
> The Params Panel UI looks like the old XUL implementation in comment 33. Do
> you come across the same problem in Nightly?

comment 33 says that in developer edition (which has the new implementation), the whole params panel is blank.
Flags: needinfo?(leyyyyy) → needinfo?(rchien)

Comment 37

2 years ago
Yes developer version has it blank.

But nightly 54.0a1 (2017-02-06) (64-bit) works fine!

You can see it here: http://4.1m.yt/gC6lzm.png


P.S. How to attach image directly in comment?
Maxim, you can upload image by clicking "attach file" in bugzilla.

Images in comment 33 looks like old XUL implementation for me. So I guess the issue has been fixed in latest build but hasn't arrived in developer edition.

ntim, does it makes sense to you?
Flags: needinfo?(rchien)
(Assignee)

Comment 39

2 years ago
(In reply to Ricky Chien [:rickychien] from comment #38)
> Maxim, you can upload image by clicking "attach file" in bugzilla.
> 
> Images in comment 33 looks like old XUL implementation for me. So I guess
> the issue has been fixed in latest build but hasn't arrived in developer
> edition.
> 
> ntim, does it makes sense to you?

My understanding of comment 33 is that the screenshots (partly working params panel) are from Firefox 51 (old version), and that developer edition has a blank params panel.

So we should uplift whatever patch that isn't on developer edition, but is on Nightly.
Flags: needinfo?(rchien)
The issue happens in old XUL implement (developer edition) but it has been fixed in Nightly (confirmed on comment 37).

I prefer not to fix this issue by uplifting because if we uplift one or two patches to fix the main issue would introduce UI inconsistency in other panels. That means we would introduce a new TreeView style ParamsPanel which built with react, but the rest of the panels would remain unchanged. As a result, I'd not prefer to uplift a series of patches for all panels due to high risk.
Flags: needinfo?(rchien)
(In reply to Ricky Chien [:rickychien] from comment #40)
> The issue happens in old XUL implement (developer edition) but it has been
> fixed in Nightly (confirmed on comment 37).
> 
> I prefer not to fix this issue by uplifting because if we uplift one or two
> patches to fix the main issue would introduce UI inconsistency in other
> panels. That means we would introduce a new TreeView style ParamsPanel which
> built with react, but the rest of the panels would remain unchanged. As a
> result, I'd not prefer to uplift a series of patches for all panels due to
> high risk.

Agreed, seems to risky - we should just let this ride the trains.
(Assignee)

Comment 42

2 years ago
(In reply to Ricky Chien [:rickychien] from comment #40)
> The issue happens in old XUL implement (developer edition) but it has been
> fixed in Nightly (confirmed on comment 37).
> 
> I prefer not to fix this issue by uplifting because if we uplift one or two
> patches to fix the main issue would introduce UI inconsistency in other
> panels. That means we would introduce a new TreeView style ParamsPanel which
> built with react, but the rest of the panels would remain unchanged. As a
> result, I'd not prefer to uplift a series of patches for all panels due to
> high risk.

How about making a specific patch for devedition ? Seems like a good compromise if we don't want to uplift all the dependencies.

Comment 43

2 years ago
Does anybody know, when the bug get fixed?
(Assignee)

Comment 44

2 years ago
Can we make a special patch for Developer Edition and simply uplift that one?
Flags: needinfo?(rchien)
I tested dev edition 53a2 (2/14) on windows and JSON params shows correctly. So it's fine for Developer Edition.


Tested with following test URL

http://jsfiddle.net/danemacmillan/LVLeS/
Flags: needinfo?(rchien)
The report from comment 30 is 3 months ago (Firefox Developer edition was v51), but now the release train has arrived to v51 and the issue already fixed current Firefox Developer edition (v53). As a result, the issue has fixed in aurora and nightly but still remain in beta and release.

I'd prefer to ride the trains since the issue seems not that critical to affect beta / release users, neither needs to uplift a hotfix for beta or release IMO.

Updated

10 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.