Closed Bug 115791 Opened 23 years ago Closed 23 years ago

Text selection in main browser window not highlighted

Categories

(Core :: DOM: Selection, defect)

defect
Not set
blocker

Tracking

()

VERIFIED FIXED

People

(Reporter: wtanaka, Assigned: mjudge)

References

()

Details

(Keywords: smoketest)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6+) Gecko/20011217 BuildID: 2001121721 In all pages, when I try to select text in the browser window, the selection occurs (I can paste into an xterm), but the text does not appear highlighted in the browser window. So it is impossible to tell visually what text is highlighted and what text is not. Reproducible: Always Steps to Reproduce: 1. Start mozilla 2. Go to a webpage (say http://www.yahoo.com/) 3. Drag the mouse over some of the text Actual Results: No visible change Expected Results: The selection should have been highlighted in black on grey, displaying what was currently selected
What's the selection background color in your current gtk theme?
An additional fact which might be useful: This behavior is reproducable on pages of all background colors (I assume -- I've tried white, black and grey) and also occurs in text widgets (like the one I'm using now) To answer Boris's question, my gtk theme background color appears (from emperical evidence collected by running the "gnp" program) to be a blue-ish gradient.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The behavior is also reproducable after a restart (I tried it just now). The reason I listed "Black on Grey" as the expected behavior is that's what I was getting for the selection color just a few builds ago.
wfm in 2001121708 linux not wfm in 2001121721 linux
Actually, this is independent of platform. In linux/win32/macos9 builds that I made this evening, there is no highlighting of any selection, whether for a drag selection in an HTML document, or just double-clicking or drag selecting in a text field (e.g., the urlbar, or a HTML form). Not particularly usable in this state. smoketest/blocker since many common operations in the tests will be difficult to perform.
Severity: major → blocker
Keywords: smoketest
OS: Linux → All
Hardware: PC → All
this wfm in 12-17-03 win2k installer.
I'm seeing this bug in 2001121806-trunk on Windows 98 using the non-talkback .ZIP install.
its in 12-18-03.. w2k.. this really is bad, how did this find its way in?
looks like some possible crash landings happenend? ;)
lame guess fingered hyatt's fix for 112980. If someone has a build, can they back this change out to verify? Here is the patch: http://bugzilla.mozilla.org/attachment.cgi?id=62005&action=view
This happens in mail headers as well, i am not able to highlight the text in the Subject line, it is possible though in the mail body
What, you're not guessing it's mjudge? He only landed major API changes to selection yesterday.
Maybe the pres shell's mDisplayNonTextSelection needs to be initialized to DISPLAY_TEXT & DISPLAY_IMAGES ? (Perhaps it should also become a PRInt16 and be renamed to mSelectionFlags?)
On win32: Any portion of a displayed mail cannot be selected (i.e. subject, body). In a compose window, subject can't, but body can.
I've got this problem with 2001121803, win-sea-insatller, Win98SE. Did not have with 20011214xx build. Time to confirm?
*** Bug 115851 has been marked as a duplicate of this bug. ***
*** Bug 115862 has been marked as a duplicate of this bug. ***
Also affects URLbar.
confirm problem both for text in the boby & URL bar for build 2001121803 on Win NT
dbaron, I think that you mean ORing the two flags together. I did that, and selection works for the content area. however, I can not select in the URL bar. :-/ Index: nsPresShell.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/base/src/nsPresShell.cpp,v retrieving revision 3.492 diff -u -r3.492 nsPresShell.cpp --- nsPresShell.cpp 18 Dec 2001 08:10:49 -0000 3.492 +++ nsPresShell.cpp 18 Dec 2001 20:15:44 -0000 @@ -1437,7 +1437,9 @@ mBidiLevel(BIDI_LEVEL_UNDEFINED), #endif mEnablePrefStyleSheet(PR_TRUE), - mScrollingEnabled(PR_TRUE) + mScrollingEnabled(PR_TRUE), + mDisplayNonTextSelection(nsISelectionDisplay::DISPLAY_TEXT | + nsISelectionDisplay::DISPLAY_IMAGES) { NS_INIT_ISUPPORTS(); #ifdef MOZ_REFLOW_PERF
fixes checked in
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 115892 has been marked as a duplicate of this bug. ***
Confirming: The Win32 build from the 2001121814 directory seems fixed.
*** Bug 115920 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
verified with commercial builds: linux 2001-12-19-08-trunk mac 2001-12-19-04-trunk osx 2001-12-19-04-trunk
*** Bug 116054 has been marked as a duplicate of this bug. ***
*** Bug 116080 has been marked as a duplicate of this bug. ***
I can confirm that this bug is fixed with build 2001121822 for solaris and corresponding build on win2000.
You need to log in before you can comment on or make changes to this bug.