193863 - Cannot get properties of items in frames.

Status: VERIFIED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Jason Bassford]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030217

When viewing a page that uses frames, the context menu item "Properties" does
not do anything when viewing an item that would normally return information
about it.

In order to get the properties of such an item, you must first "Show Only This
Frame".

Reproducible: Always

Steps to Reproduce:
1. View the testcase which I will attach in a comment to follow.
2. Right click on either of the "URL" links and select "Properties".

Actual Results:  
Nothing happens.  (The only way to get the information is to view the single
frame on its own.)

Expected Results:  
The properties of the URL hyperlink should appear.

Comment 1

[Jason Bassford]

Attachment: Testcase.

Comment 2

[Boris Zbarsky [:bzbarsky]]

linux trunk build 2003-02-17-08, when following the steps in comment 0 I get a
little window that lists the href URL and the target frame....

Comment 3

[Jason Bassford]

It must be OS specific then...

Comment 4

[Madhur Bhatia]

I am able to view link property information on the winXP trunk build
2003-02-17-04.  WFM.

Comment 5

[Jason Bassford]

I just verified that with a new profile and a clean install I have the same
problem - I can only see the property of the URL if I view a single frame.

The fact that somebody else on XP doesn't see this baffles me.

Comment 6

[Jason Bassford]

I just checked this on another computer running XP and a 2/18 build - it worked
fine.

I've now done an "aggressive" uninstall of Mozilla on my computer (manually
ripping out lingering Mozilla references in the registry), before doing a clean
install to no avail.  There's obviously something strange going on with my
system, and I'm not sure what further troubleshooting I can do.  Something's
causing this, I just don't know how to identify what it is.

Comment 7

[Boris Zbarsky [:bzbarsky]]

XUL.mfl trouble, maybe?

Comment 8

[Jason Bassford]

I don't see how.  Like I said, I've deleted *everything* (after making backups
of course) and on a completely new install (new program directory, plugins,
profile, registry entiries, etc.) the same thing happens.  The only thing left I
can think of is a conflict with some other piece of software I have installed. 
But I can't for the life of me think what it would be that would cause SO
specific a problem as this.  (I can see element properties, just not in frames.)
 I even updated my Java runtime from 1.4.1 to 1.4.1_01 - not that I can see how
that could have been the culprit.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Hmm... are you using anything like TweakUI or something like that?

Comment 10

[Jason Bassford]

Why, yes.  However, it's not the Control Panel applet version that you install -
it's a standalone EXE that I only load when I want to change settings.  (This is
the one that the developers had on the MS site - v2.00.0.0 - before it was
yanked in favour of a version that didn't do as much.)

Was there a particular setting you had in mind?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Yeah, click-to-focus vs focus-follows-mouse...

Comment 12

[Jason Bassford]

I've never used "Activation follows mouse" - I also did check to make sure that
there was no "Element Properties" window that had popped up beneath the
<frameset> document that I was just not seeing.  There's simply no window being
created for me.

Comment 13

[Jason Bassford]

If I can't isolate what's causing this problem, then I can't outline how to
reproduce it and I suppose I should mark the bug INVALID and just live with it
on my system.  (Grr.)

FWIW: IE works just fine on my system, so it's specific to Mozilla but not to
any of the files / settings it's using itself.

Before I close this bug, though, is there any kind of debug option I could turn
on that might generate something useful here?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Well....  You get a context menu, right?  You could unjar the relevant
chrome and put dump statements in nsContextMenu.js or contentAreaContextOverlay.xul
(wherever the window is opened from) and in the properties window's onload
method to see whether that fires...

Let me know if you have trouble finding the relevant code and I can
point you to it or maybe even produce a patch to try (to apply with
PatchMaker).

Comment 15

[Jason Bassford]

Okay.

I've verified that when I select Properties after right-clicking on the
hyperlink in the <frameset>, the "showMetadata : function ()" code from
nsContextMenu.js does NOT get executed.  (But other context menu items for the
hyperlink, such as "Save Link Target As..." do work.)

So - what would be preventing that function from being called?

Comment 16

[Jason Bassford]

Whoa!  After adding dump statements (alerts) to all of the Metadata sections of
code in nsContextMenu.js (and constantly dismissing the dialogues) the Element
Properties window suddenly started to appear.

Why simply adding alerts into the code would make it work, I don't know. 
(Perhaps there's some kind of timing issue?)

In any case, I will try to narrow down the point in the code where an alert
statement makes a difference for me and supply further information shortly.

Comment 17

[Jason Bassford]

All right, here it is.

It doesn't matter where in the code I put an alert(), just so long as at least
one alert is displayed at some point between the time when I right-click on the
element then left-click on "Properties".

If there is no alert(), Properties produces nothing if I'm looking at a
<frameset> document.  If there IS an alert, Properties works just as it should.

Also, it can't be a timing issue because it doesn't matter how long I wait
between bringing up the context menu and clicking on Properties - if there's no
intervening alert it doesn't do anything.

Which means that the display of an alert seems to be altering some required code
value that will enable "showMetadata : function ()" to be called.

I'm now totally stumped.  But I've left the alert in so that I now at least have
a workaround to this bug...

Comment 18

[Boris Zbarsky [:bzbarsky]]

Sounds like a timing issue to me (doing an alert means you will go out
to the main event loop, no matter how little time you spend on the alert).

Are there any errors in the JS console when this fails?  If you use
dump() instead of alert() (may need to enable this in debug prefs) do
you still see the problem go away?

Comment 19

[Jason Bassford]

The JS Console doesn't activate with the testcase for me, and using debug()
rather than alert() does not fix the problem - only alert() works.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Definitely sounds like a win32 timing issue... danm?  any ideas?

Comment 21

[Jason Bassford]

Correct.  I was being an idiot and looking for the Sun Java JSE console.  Using
"chrome://global/content/console.xul", I see the following thrown when using
dump(): "Error: gContextMenu has no properties."

Incidentally, how is console.xul evoked via the menus?  (This is the first time
I've called it up, and luckily stumbled across a reference to accessing it in a
Newsgroup this morning.)

Comment 22

[Jason Bassford]

s/correct/correction

Comment 23

[Christian :Biesinger (don't email me, ping me on IRC)]

>how is console.xul evoked via the menus?

Tools|Web Development|Javascript console

Comment 24

[Jason Bassford]

Doh!  Here I was looking under Debug, I never would have thought of Web
Development...

Comment 25

[Boris Zbarsky [:bzbarsky]]

jag, any idea why gContextMenu would be null in a timing-dependent way?

Comment 26

[Boris Zbarsky [:bzbarsky]]

Does the patch in bug 195878 help?

Comment 27

[Jason Bassford]

Yes.  Confirming that applying the patch for bug 195878 fixes this bug.

Comment 28

[Jason Bassford]

Confirming fixed by fix for bug 195878.

Comment 29

[Jason Bassford]

.