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

Status: VERIFIED FIXED

(DevTools :: Netmonitor, defect, P3)

Description

[cvetan.simsic]

Attachment: 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.

Comment 1

[Dane MacMillan [:danemacmillan]]

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.

Comment 2

[Dane MacMillan [:danemacmillan]]

Here's a test case:

http://jsfiddle.net/danemacmillan/LVLeS/

Comment 3

[Tim Nguyen :ntim]

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.

Comment 4

[Dane MacMillan [:danemacmillan]]

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

Comment 5

[Tim Nguyen :ntim]

[Tracking Requested - why for this release]: Regression in developer tools

Comment 6

[Tim Nguyen :ntim]

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 :)

Comment 7

[Tim Nguyen :ntim]

Attachment: Patch

I'm not sure what use case the `onlyEnumVisible: true,` argument fixes here, really.

Comment 8

[Tim Nguyen :ntim]

Attachment: Patch v1.1

Comment 9

[Tim Nguyen :ntim]

(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 10

[Victor Porof [:vporof][:vp]]

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.

Comment 11

[Tim Nguyen :ntim]

Attachment: Patch v2

Comment 12

[Tim Nguyen :ntim]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8b98ef66071d

Comment 13

[Jeff Griffiths (:canuckistani) (:⚡︎)]

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?

Comment 14

[cvetan.simsic]

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

Because it is still the same.

Comment 15

[Tim Nguyen :ntim]

(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 16

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/10ddceabece0

Comment 17

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/10ddceabece0

Comment 18

[Tim Nguyen :ntim]

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]:

Comment 19

[Dane MacMillan [:danemacmillan]]

Thanks--this is working in Nightly!

Comment 20

[cvetan.simsic]

Still not in dev edition though.

Comment 21

[Tim Nguyen :ntim]

(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.

Comment 22

[Sylvestre Ledru [:Sylvestre]]

Recent regression, tracking.

Comment 24

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/7a252423e73b

Comment 25

[cvetan.simsic]

I've just updated dev edition, the parameters still don't show up.

Comment 26

[Sylvestre Ledru [:Sylvestre]]

Yes, the patch landed 6 minutes ago. It should be in tomorrow aurora build (or the day after).

Comment 27

[cvetan.simsic]

It landed in dev edition. :)

Thanks guys.

Comment 28

[Nazir Ahmed Sabbir [:NaSb]]

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

Comment 29

[Mohammad Maruf Islam]

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!

Comment 30

[[e-mail]]

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

[Maxim]

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?

Comment 32

[Tim Nguyen :ntim]

Attachment: 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 ?

Comment 33

[Maxim]

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.

Comment 34

[Tim Nguyen :ntim]

Honza, Ricky, Jarda, might be a regression from the netmonitor html changes ?

Comment 35

[Ricky Chien [:rickychien] (inactive)]

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 36

[Tim Nguyen :ntim]

(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.

Comment 37

[Maxim]

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?

Comment 38

[Ricky Chien [:rickychien] (inactive)]

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?

Comment 39

[Tim Nguyen :ntim]

(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.

Comment 40

[Ricky Chien [:rickychien] (inactive)]

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.

Comment 41

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(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.

Comment 42

[Tim Nguyen :ntim]

(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

[armin]

Does anybody know, when the bug get fixed?

Comment 44

[Tim Nguyen :ntim]

Can we make a special patch for Developer Edition and simply uplift that one?

Comment 45

[[e-mail]]

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/

Comment 46

[Ricky Chien [:rickychien] (inactive)]

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.