Is there any way to find these Javascript uses from following the trail from right-clicking on the submit button in question and then selecting Inspect Element with Firebug? Or must I continue to search through the source code of all the Javascript files for the string "submitSearchForm"?
jQuery doesn't attach the event handler directly to the element. It uses internal mechanisms for this purpose.
What you can do to debug the code inside the click() function is to enable the *Script* panel <https://getfirebug.com/wiki/index.php/Script_Panel> set a breakpoint at the e.preventDefault(); line and click the #submitSearchFormbutton. The debugger will stop at that line. Then you're able to use step debugging to check what's going on.
Sebastian
PS: Using <button> tags for buttons offers more flexibility in designing the button contents (independently from the value that will be sent).
> What you can do to debug the code inside the click() function is to enable
> the *Script* panel <https://getfirebug.com/wiki/index.php/Script_Panel> set
> a breakpoint at the e.preventDefault(); line and click the #submitSearchFormbutton.
If you don't know where the e.preventDefault90 line actually is in the
code,
you can use "break on next" feature
1) Enable the script panel (refresh the page)
2) Activate Break on next by clicking on the 'pause' button at the
left side of the Script panel toolbar
3) Click the #submitSearchFormbutton button on your page
4) The debugger should break on the first executed line
Honza
On Sep 24, 10:21 pm, Sebastian Zartner <sebastianzart...@gmail.com>
wrote:
> jQuery doesn't attach the event handler directly to the element. It uses
> internal mechanisms for this purpose.
> What you can do to debug the code inside the click() function is to enable
> the *Script* panel <https://getfirebug.com/wiki/index.php/Script_Panel> set
> a breakpoint at the e.preventDefault(); line and click the #submitSearchFormbutton. The debugger will stop at that line. Then you're able to use step
> debugging to check what's going on.
> Sebastian
> PS: Using <button> tags for buttons offers more flexibility in designing
> the button contents (independently from the value that will be sent).
On Mon, Sep 24, 2012 at 11:21 PM, Sebastian Zartner
<sebastianzart...@gmail.com> wrote:
> jQuery doesn't attach the event handler directly to the element. It uses
> internal mechanisms for this purpose.
> What you can do to debug the code inside the click() function is to enable
> the Script panel set a breakpoint at the e.preventDefault(); line and click
> the #submitSearchForm button. The debugger will stop at that line. Then
> you're able to use step debugging to check what's going on.
That method assumes that I know where the click() function is. My goal
is quite to find where that function may be. I apologise for not
making that clear.
> Sebastian
> PS: Using <button> tags for buttons offers more flexibility in designing the
> button contents (independently from the value that will be sent).
Thank you. I am just getting into Javascript development so advice
like this is very much appreciated. In fact, if you have any preferred
learning or reference resources then I would love to know about them,
especially for object-oriented Javascript as the prototype model is
very foreign to my C++ / C# / Java brain. Most of the information that
I have been able to Google for is extremely low quality or
uninformative (mostly blog posts from novices such as myself).
On Tue, Sep 25, 2012 at 10:29 AM, Jan Honza Odvarko <odva...@gmail.com> wrote:
>> What you can do to debug the code inside the click() function is to enable
>> the *Script* panel <https://getfirebug.com/wiki/index.php/Script_Panel> set
>> a breakpoint at the e.preventDefault(); line and click the #submitSearchFormbutton.
> If you don't know where the e.preventDefault90 line actually is in the
> code,
> you can use "break on next" feature
> 1) Enable the script panel (refresh the page)
> 2) Activate Break on next by clicking on the 'pause' button at the
> left side of the Script panel toolbar
> 3) Click the #submitSearchFormbutton button on your page
> 4) The debugger should break on the first executed line
> Is there any way to find these Javascript uses from following the trail > from right-clicking on the submit button in question and then selecting > Inspect Element with Firebug? Or must I continue to search through the > source code of all the Javascript files for the string "submitSearchForm"?
On Tuesday, September 25, 2012 3:33:00 PM UTC+2, Avenger wrote:
> There is a FireBug-Extension called "FireQuery", which helsp trace the > events connected to ein element.
Right, FireQuery is also a good extension for jQuery users.
Also there is another extension called Eventbug, which allows investigating all assigned JavaScript events. More extensions can be found at our extensions page<https://getfirebug.com/wiki/index.php/Firebug_Extensions>in the wiki.
On Tue, Sep 25, 2012 at 3:42 PM, Sebastian Zartner
<sebastianzart...@gmail.com> wrote:
> On Tuesday, September 25, 2012 3:33:00 PM UTC+2, Avenger wrote:
>> There is a FireBug-Extension called "FireQuery", which helsp trace the
>> events connected to ein element.
> Right, FireQuery is also a good extension for jQuery users.
> Also there is another extension called Eventbug, which allows investigating
> all assigned JavaScript events.
> More extensions can be found at our extensions page in the wiki.
Great, thank you. I will look at FireQuery and Eventbug, both of which
seem relevant. I did not realize that Firebug itself is extensible.
On Tue, Sep 25, 2012 at 1:43 PM, Sebastian Zartner
<sebastianzart...@gmail.com> wrote:
> Ok. For that purpose it's better to use Break On Next as Honza described it.
> Also note that there is a search field, which you can use to find
> appearances of keywords like "submitSearchForm" in your code.
Great, thanks.
> If you want to learn more about Firebug, you can also read other articles in
> our wiki.
Yes, I am going through the wiki. I feel sorry for JS developers that
had to do without Firebug at some time: it really is an indispensable
tool for anything beyond the JS basics.
>> > Sebastian
>> > PS: Using <button> tags for buttons offers more flexibility in designing
>> > the
>> > button contents (independently from the value that will be sent).
>> Thank you. I am just getting into Javascript development
> In this case it was a tip for HTML, not JavaScript. :-)
True, I shouldn't lump client-side technologies in the same basket as
I mentally do.
> There are several good tutorials, references and tips and tricks pages for
> HTML, JavaScript and CSS.
Thank you very much. I have actually read some of those, especially
the excellent W3Schools tutorials. It looks like I will need to
purchase a "real book" PDF for advanced Javascript, though. I have no
qualms about that. One thing that I do have qualms about is testing
Javascript in other runtimes (browsers) without Firebug! I see that
Chrome has some Firebug-clone debugging tools.
> Thank you very much. I have actually read some of those, especially > the excellent W3Schools tutorials. It looks like I will need to > purchase a "real book" PDF for advanced Javascript, though. I have no > qualms about that.
Yes, buying a book is a good idea.
> One thing that I do have qualms about is testing > Javascript in other runtimes (browsers) without Firebug! I see that > Chrome has some Firebug-clone debugging tools.
Opera and IE also have dev tools, though of course they are not as good as Firebug. :-)
