Closed Bug 64349 Opened 24 years ago Closed 23 years ago

implement nsIWebBrowserFocus

Categories

(Core Graveyard :: Embedding: APIs, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.4

People

(Reporter: blizzard, Assigned: blizzard)

References

Details

(Keywords: embed, Whiteboard: needed by 05/08/01)

Attachments

(1 file)

From:

http://www.mozilla.org/projects/embedding/apiReviewNotes.html#nsIWebBrowserFocus

[12/14/00]
Proposed idl
       void activate();
       void deactivate();

        // Give the firstelementfocus within mozilla
       // (ie. TAB was pressedand focus should enter mozilla)
       void setFocusAtFirstElement();

       // Give the last element focus within mozilla
              // (ie ALT-TAB was pressed andfocus should enter mozilla)
       void setFocusAtLastElement();
       attribute nsIDOMWindowfocusedWindow;
       attribute nsIDOMElementfocusedElement;

nsWebBrowser.cpp has some Activate() impl that could/should be leveraged here.
nominating 0.8
Keywords: embed, mozilla0.8
Updating QA Contact
QA Contact: jrgm → mdunn
Blocks: 64833
Mozilla 0.8 builds started today. We would consider taking reviewed low risk 
fixes if they are available today (Wednesday, 7/Feb/01) or tomorrow (Thursday, 
8/Feb/01). Otherwise, please retarget it for Mozilla 0.9.
Target Milestone: --- → mozilla0.9
Blocks: 70229
Keywords: mozilla0.8.1
Keywords: mozilla0.8
Target Milestone: mozilla0.9 → mozilla0.9.1
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
I attached an implementation of nsWebBrowser::GetFocusedElement.  It is nearly 
identical to the existing code for GetFocusedWindow().  I may look into 
implementing the remaining bits of the nsIWebBrowserFocus if I have some time 
here.  
patch looks right to me. r=saari
Yeah, looks great to me except for the fact that it isn't a diff with -u and is
hard to read. :)

sr=blizzard
Blocks: 75664
Whiteboard: needed by 05/08/01
Bug: Run mfcembed.exe, 0.9 mozilla, goto http://www.yahoo.com, after page 
loaded click to set focus on the URL field of the main window, then click on 
yahoo's text input field and type something, the output is expected to go into 
the search field, but it goes into the URL field.

Cause: When use clicks on the content, nsIWebBrowserFocus::Activate() is not 
called if the main window never lose focus. Hence the content is not activated.

Could the browser content activate itself when it receives mouse click and 
deactivate when mouse click outside of it?
It probably should. In the PPEmbed sample, it works just that way.
04/23/01 13:52 patch checked in:

Checking in nsWebBrowser.cpp;
/cvsroot/mozilla/embedding/browser/webBrowser/nsWebBrowser.cpp,v  <-- 
nsWebBrowser.cpp
new revision: 1.81; previous revision: 1.80
done
Does this patch fix our focus problems?
Just talk to Alex, his patch has nothing to do with the problem specified, this 
is simply reproducible with mfcembed.exe. You can see two cursors (one in url 
field and one in the browser area) and text goes into the url field. 
edxu@hotmail.com, could you create a new bug bugzilla bug describing the problem 
that you have in mfcembed.exe (including the steps to reproduce it). I believe 
the existing problem in this bug is resolved.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
No longer reproducible, I think it has been fixed.
Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
This was fixed a while ago.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
checked code checkin in nsWebBrowser.cpp, in local mozilla build and lxr.
Haven't seen focus problem in mfcEmbed.
Status: RESOLVED → VERIFIED
No longer blocks: 64833
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: