Bugzilla – Full Text Bug Listing
| Summary: | Ctrl+V goes to a wrong handler on the "Add Repository"dialog | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Oleg Besedin <ob1.eclipse> | ||||
| Component: | UI | Assignee: | Remy Suen <remy.suen> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Paul Webster <pwebster> | ||||
| Severity: | critical | ||||||
| Priority: | P3 | CC: | bokowski, john.arthorne, ob1.eclipse, remy.suen | ||||
| Version: | 1.0 | Flags: | remy.suen:
review+
|
||||
| Target Milestone: | 1.0 RC2 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Oleg Besedin
Its pretty bad as 1) a person tas to type in P2 site URIs - can't copy/paste; 2) this causes a bunch of NPEs later on, including immortal modal dialog. When the 'Add...' button is clicked, the active part is flagged as one can see from the blue gradient background. When the nested modal dialog is about to appear, the outer modal dialog is deactivated, altering the active context chain to once again point down to the part. When the modal dialog itself is activated, we ask the parent context (the outer modal dialog) to activate the nested dialog's context. This is done but this change is not propagated upwards. So you get something like... Application (active) +MWindow (active) ++MPerspective (active) +++MPart (active) ++Outer modal shell +++Nested modal shell (active) ...which causes the keybindings to be delivered to the part instead. (In reply to comment #2) > So you get something like... > > Application (active) > +MWindow (active) > ++MPerspective (active) > +++MPart (active) > ++Outer modal shell > +++Nested modal shell (active) > > ...which causes the keybindings to be delivered to the part instead. To be clear, the expected sequence would be... Application (active) +MWindow (active) ++MPerspective +++MPart (active) ++Outer modal shell (active) +++Nested modal shell (active) ...of course, this presents the problem we see right now wherein the tab folder stays white even though we'd expect there to still be an "active part". This still occurs in I20100701-1105. It is not only Paste, but also Home, End, etc do not work in this dialog. Created attachment 173587 [details] ShellActivationListener patch v1 This patch implements the propagation fix described by comment 2 and also ensures that we are never pointing at a disposed context for an active child. Paul, what do you think? (In reply to comment #5) > Created an attachment (id=173587) [details] > ShellActivationListener patch v1 > > Paul, what do you think? This makes perfect sense, and I gave it a whirl. It also seems self correcting. Could you make a quick test of some of our main dialogs like Commit, Search, and breakpoint properties/conditional breakpoints for things like content assist, Home, End, CTRL+ARROW. If it seems fine, commit it and I'll do a build submission just before the build tonight at around 19:00 PW (In reply to comment #6) > Could you make a quick test of some of our main dialogs like Commit, Search, > and breakpoint properties/conditional breakpoints for things like content > assist, Home, End, CTRL+ARROW. Content assist in the breakpoint and search dialogs and home/end stuff seems to be fine. Fix released to HEAD. |