Venkman should track source as loaded by the browser

ASSIGNED
Assigned to

Status

Other Applications
Venkman JS Debugger
P3
normal
ASSIGNED
17 years ago
9 years ago

People

(Reporter: Henrik Gemal, Assigned: Robert Ginda)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [native], URL)

(Reporter)

Description

17 years ago
if you start the js debugger and go to http://mail.opasia.dk
and in the debugger open the link http://web.mail.opasia.dk/webmail....
and click on the function "local_init" the js debugger doesn't high light the
function...
I'm seeing this in the js console. Not sure if it's relevant:

Error: column has no properties
Source File: 
Line: 18 

Error: column has no properties
Source File: 
Line: 32

build 20011118
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P3
(Assignee)

Comment 1

17 years ago
This looks like it's because we refetch the source from the server, instead of
using the source we actually got from the server the first time.  I'll need to
fix this for moz 1.0.

cc'ing jst who's going to have to sr= the DOM changes.
Whiteboard: [native]
Target Milestone: --- → mozilla1.0
(Assignee)

Updated

17 years ago
Summary: function not highlighted in source when selected → Venkman should track source as loaded by the browser

Comment 2

17 years ago
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
(Assignee)

Updated

17 years ago
Target Milestone: mozilla1.2 → mozilla1.0
(Assignee)

Comment 3

17 years ago
I'm going to push this out, Pretty Print can always be used to see the "real"
source when all else fails.
Target Milestone: mozilla1.0 → Future

Comment 4

16 years ago
This causes a real problem for developing JSPs, especially when there is no real
referrer URL (we hide everything in a generic servlet name). Although pretty
print will allow the debugger to show the actual script function to facilitate
debugging, attempting to open the actual page source causes Venkman to refetch
the page and the server spits out an error page.

Interestingly enough, if one closes the debugger and then reopens it after a JSP
has loaded, you get to see all the page-declared functions under the page's
generic name and they are viewable (pretty print enabled). Any attempt to fetch
the page source and everything flies out of the loaded scripts pane for the
page. Loading a new page causes this same behaviour (loss of page-declared
functions) though they do display if the debugger kicks in.

Just a plea to fix this behaviour as we work exclusively with JSPs.

TIA.
(Assignee)

Comment 5

16 years ago
You might try turning off the "Exclude Duplicates" item in the context menu of
the Loaded Scripts view.  With this option on, Venkman will only show the
*latest* version of a particular file, which is probably why you notice your
functions go away when you load a new page.  That might make it possible to work
with Pretty Print in the meantime.
OS: Windows 2000 → All
Target Milestone: Future → ---
Product: Core → Other Applications

Updated

9 years ago
Duplicate of this bug: 455014

Updated

9 years ago
QA Contact: rginda → venkman
You need to log in before you can comment on or make changes to this bug.