0

I'm trying to find the cause of an unwanted value modification so I can remove the bug. When I turn off javascript for my page it includes this element after loading:

<input type="hidden" value="5123" name="report[sub_district_id]" id="report_sub_district_id">

but when I have javascript on, the same element looks like this after page load:

<input type="hidden" value="" name="report[sub_district_id]" id="report_sub_district_id">

I can't work out what code is unsetting the value property.

I've got one method that I know of that modifies the value. I've tried putting an alert in that method, but it's not triggered. I've also tried commenting out that method, but still the change happens. Perhaps some of my other JS accidentally hooks onto this element, but it seems unlikely. Perhaps the change is caused by some code in my framework (Rails with Materialize).

I've also tried adding DOM breakpoints "attribute modified" and "subtree modified" on this element, and "subtree modified" on the parent element, but none of these breakpoints are triggered.

The "attribute modified" breakpoint does trigger when my code modifies the value of the input at some point after the page is loaded, but I'm trying to find what is happening when "page:change" event is triggered, and this breakpoint is not triggering - perhaps because the DOM is not loaded yet.

I've tried the answers to this question but they don't help because they don't show how to make a breakpoint on an element change event that triggers before the DOM is loaded.

I'm using Chromium browser 48.0.2564.116 on Ubuntu 15.10 (64-bit)

How can I find what the cause of this bug is?

Community
  • 1
  • 1
Toby 1 Kenobi
  • 4,717
  • 2
  • 29
  • 43
  • how can you add a breakpoint during loading? maybe you can stop the loading early, set the breakpoint, and continue... or, just delete the element before it's changed and look at the error that throws when something tries to change it, should have a stack... – dandavis Mar 29 '16 at 04:24
  • It could be anything. We need more to go on. – Sverri M. Olsen Mar 29 '16 at 04:25
  • I set the breakpoint, then reload the page. Since the breakpoint is still there after reloading the page I'm assuming that it's active during page loading. Is that wrong? – Toby 1 Kenobi Mar 29 '16 at 04:25
  • @Toby1Kenobi: no, that sounds ok, they must have improved it, sorry. – dandavis Mar 29 '16 at 04:26
  • @SverriM.Olsen exactly. I don't even know where to start narrowing this down. It could be anything. If you can specify what more you want to see that might help. – Toby 1 Kenobi Mar 29 '16 at 04:29
  • Instead of relying on DOM breakpoints, if you're pretty sure that some javascript is the problem, you could come at it from the other end and do a global search for "report_sub_district_id" or "report[sub_district_id]". In the chrome dev tools, ctrl+shift+f will search ALL files (except the original HTML file). You might get some hits from there and then press the prettify button on the source if it's minified. Also, since that searches all but the original HTML file, you can also take the content of the original HTML response in the network tab and copy/paste to an editor and search there. – Scott Mar 29 '16 at 04:34
  • I found the problem. It was some of my other code accidentally hooking the element like this: `$('#parent-div-id input').val('')`. So that wouldn't have turned up with your idea @Scott. Still I don't know why the breakpoints didn't trigger - so my question (i.e. how to find a bug like this) still stands. – Toby 1 Kenobi Mar 29 '16 at 04:43
  • Possible duplicate of [Using Chrome, how to find who's binded to an event?](http://stackoverflow.com/questions/7338193/using-chrome-how-to-find-whos-binded-to-an-event) – jmargolisvt Mar 29 '16 at 04:44
  • 2
    @Toby1Kenobi I deal with stuff like this every single day but without knowing what your code does I would just be guessing. Use breakpoints, look for code that may touch stuff that it shouldn't be able to touch, etc. As a last resort you can also try to pinpoint the problem by simply removing chunks of your code until the bug disappears. – Sverri M. Olsen Mar 29 '16 at 04:44
  • The reason the breakpoints didn't trigger may be because before the DOM is loaded... – superui Mar 29 '16 at 05:02

2 Answers2

1

Debug after insert this code on top line of your page.

setInterval(function() {
  var value = $("#report_sub_district_id").val();
  if(value !== 5123) debugger;
},10);

and, Maybe any Chrome extension program might cause the problem. You should disable your all Chrome extensions.

superui
  • 654
  • 5
  • 10
1

TL;DR is there's no easy way.

So working backwards from the code that was actually changing, I don't think there is a way with browser's debugging tools to put a breakpoint here. However with an educated guess about the dom node's property that was getting changed, you could (assuming you run soon enough in the page) set a breakpoint that would help you out.

You found that the code in question was $('#parent-div-id input').val('').

Now .val() in jQuery just finds the actual node element and sets node.value = "blah"; The important distinction here is that it was changing a "property" on the node, and not an "attribute". You'll notice that all the DOMAttribute etc breakpoints talk about node attributes. If you take a node and edit the html's attribute, by say doing $('#parent-div-id input').attr('value', 'blah'), the breakpoint would get hit. The list of properties on a node is much larger than the list of HTML attributes, and the debugging tools only put breakpoints on HTML attribute modifications.

However in this case, you know the element in question (the input element), and the property that was getting messed with (the value property), so you could have done what was suggested in this answer, and redefined the property.

Example code here:

var node = $('#parent-div-id input')[0];
Object.defineProperty(node, 'value', {
    get: function () {
        return node._value;
    },

    set: function (value) {
        debugger; // sets breakpoint
        node._value = value;
    }
});

All you'd need to do is get that code to run early enough in the page. To do that I'd probably set a breakpoint on the first line of the first javascript file loaded in the network tab.

Community
  • 1
  • 1
Scott
  • 954
  • 1
  • 8
  • 15