Last modified: 2012-12-04 23:10:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T11366, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 9366 - When you double-click to edit MediaWiki should highlight the appropriate word in the edit textbox
When you double-click to edit MediaWiki should highlight the appropriate word...
Status: VERIFIED WONTFIX
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-22 09:20 UTC by Jason Spiro
Modified: 2012-12-04 23:10 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jason Spiro 2007-03-22 09:20:54 UTC
MediaWiki lets users with double-click editing enabled edit pages just by
double-clicking anywhere on the page.  But I would appreciate it if, when you
double-click to edit, the editing textbox automatically highlighted the word you
double-clicked.

See also related idea: bug 9367.
Comment 1 Brion Vibber 2007-03-22 13:59:44 UTC
This would require wrapping every word in some kind of <span> with attached
information about where in the source text it occurred. Even if we could figure
out how to do that in the parser, it would increase our bandwidth requirements
several times, costing us tens of thousands of dollars per month.

So... probably not right now. :)
Comment 2 Brion Vibber 2007-03-22 14:00:36 UTC
*** Bug 9367 has been marked as a duplicate of this bug. ***
Comment 3 Jason Spiro 2007-03-22 23:17:52 UTC
I'm not 100% sure but it seems you don't have use DIVs.  A Google search for:

javascript "clicked word"

finds a variety of relevant results.  So, I am taking the liberty of reopening this.

Anyway, even if you choose not to provide word-level granularity, you could
still provide paragraph-level granularity; it probably wouldn't be as hard.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-03-22 23:25:24 UTC
The basic problem is we currently have no idea what parts of the rendered page correspond to what 
parts of the markup.  Some parts may be templates, for instance, or any number of other things.  
Plausibly future improvements in Web technology or how pages are stored or something might make 
this possible, so I'll call it LATER, but this is not practical at the moment.  If you disagree, 
please provide a patch to the code that will implement this.  Do not reopen this bug otherwise.
Comment 5 Jason Spiro 2007-03-23 01:20:45 UTC
(In reply to comment #4)
> The basic problem is we currently have no idea what parts of the rendered page
correspond to what 
> parts of the markup.  Some parts may be templates, for instance, or any number
of other things.  
...

If the feature I am requesting only worked 95% of the time, that would still be
wonderful.

(Then, later on, if the parser were made to output <span class="template"> tags
as [[meta:WYSIWYG editor]] describes, the feature could be improved and made to
work all the time.

Why is a 95% solution unacceptable?
Comment 6 Andre Klapper 2012-12-03 16:54:31 UTC
(In reply to comment #5)
> Why is a 95% solution unacceptable?

Because people expect 100% & will file bug reports about the remaining 5%. Moving from deprecated "LATER" to "WONTFIX" resolution as per comments.
Comment 7 Jason Spiro 2012-12-04 23:10:34 UTC
I thank you all for your feedback on this bug.

I've just filed an easier-to-implement alternative:

Bug 42701:  "When I double-click to edit, please scroll the edit area to the section I double-clicked".

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links